I have an application which uses an ELK with ElasticSearch version 6.2 (jhipster-console), plus another Elastic instance for my applicative document repository (for now a 2.4.6 version, as I'm on spring-data-elasticsearch 2.1.11).
Will I be able to use only one Elastic runtime when migrating to spring-boot 2 (so spring-data Kay SR6 suite) for both needs?
Side question, is it recommended to have only one Elastic datasource for both needs (applicative + monitoring)?
Related
I have an Angular6-App with a PouchDB 7 where I plan a replication to a CouchDB-Server. The current option is a CouchDB-Server in version 1.6 only.
So the question is, if a replication form PouchDB in version 7 to this CouchDB in version 1.6 can work (for a two-way-replication so that different Angular-Clients can exchange changes over this CouchDB-Server).
I can't find any compatibillity list in the net to this topic...
Some hint's would be apprieciated.
CouchDB and PouchDB use the same replication protocol. There are some optimizations introduced in CouchDB 2.x, but PouchDB 7 will still be able to sync without a problem in CouchDB 1.6.
However, you absolutely should not use CouchDB 1.6!! 1.6 had some very serious security flaws, which can essentially allow anyone to execute arbitrary code on your server. These were fixed in 1.7 and later. So please upgrade to at least 1.7.1 immediately!
We use an "enterprise" app which deploys Hazelcast. Every minor version upgrade is a pain, because the vendor has to become involved.
Any chance Hazelcast.org could deploy a hazelcast-api.jar on which the legacy app could depend at compile-time, leaving us free to deploy the compatible version of our choice for runtime use?
Thanks, Robin.
Robin,
Currently it's not possible we at Hazelcast have this requirement in mind for future hazelcast versions (maybe in Hazelcast 4).
Let me know if you have an questions.
I am trying to deploy an Akka application on Azure, that uses the journal persistence plugin.
I cannot find a working combination when it comes to the persistence plugin I should use.
So far I looked into:
akka-persistence-mongo and Azure Document Store with Mongo driver: it does not work because akka-persistence-mongo is not compatible with the latest reactive-mongo version that supports SSL
akka-persistence-jdbc and an Azure SQL server: it seems the akka-persistence-jdbc is only compatible with Slick H2, Oracle and MySQL drivers
I do not have any strong performance requirements, this is why both solutions would have worked.
My best guess for the moment is akka-persistence-redis with Microsoft Azure Redis.
I am proposing a contribution to this plugin to make it compatible with Microsoft Azure Redis (authentication, as well as a strange error when calling zrangebyscore that I do not have with a local Redis).
I'm currently building an application using the ReliableActors framework on Azure ServiceFabric. As we scale up, I'm looking at doing blue/green deployments. I can see how to do this using a stateless system. Is there's a way to do this using statefull actors?
Service Fabric is all about rolling upgrades, rather than deployment swaps, like a VIP swap. Both stateless and stateful services are upgraded the same way, but there are a few additional nuances to stateful that I'll mention later.
By rolling upgrades, I mean upgrades to an application are done in place, one upgrade domain at a time, so that there is no downtime and no sudden switch. A rolling upgrade in Service Fabric can be done in a safe "managed" mode where the platform will perform health checks before moving on to the next upgrade domain, and will automatically roll back if health checks fail.
OK, that all sounds nice. But how do you do blue/green deployments when upgrades are always rolling upgrades?
This where application types and version come in. Instead of having two "environments" that can hold two running applications, Service Fabric has this concept of versioned application types from which application instances can be created. Here's an example of how this works:
Let's say I want to make an application called Foo. My Foo application is defined as an application type, call it FooType. This is similar to defining a class in C#. And like class in C#, I can create instances of my type. Each instance has a unique name, similar to how each object instance of a class has a unique variable name. But unlike classes in C#, my FooType has a version number. Then I can "register" the application type and version in my cluster:
FooType 1.0
With that registered, I can create an instance of that application:
"fabric:/FooApp" of FooType 1.0
Now, let's say I develop version 2.0 of my application. So I register version 2.0 of my FooType in the cluster:
FooType 1.0
FooType 2.0
Now I have both versions of FooType registered, and I still have an instance of 1.0 running:
"fabric:/FooApp" of FooType 1.0
Here's where it gets fun. I can do some interesting things:
I can take "fabric:/FooApp" - an instance of FooType 1.0 - and upgrade it to FooType 2.0. This will be a rolling upgrade of that running application.
Or.. I can leave "fabric:/FooApp" alone, and create a new instance of my version 2.0 application:
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
Now I have two applications, running side-by-side, in the same cluster. One is an instance of 1.0, and the other is an instance of 2.0. With some configuring of ports and application endpoints, I can ensure users are still going to the 1.0 instance while I test out the 2.0 instance.
Great, so all my tests pass against the 2.0 instance, so now I can safely take the 1.0 instance and upgrade it to 2.0 of FooType. Again, this is a rolling upgrade of that instance (fabric:/FooApp), it's not migrating users to the new instance (fabric:/FooAppv2Test). Later I'll go and delete fabric:/FooAppv2Test because that was just for testing.
One of the benefits of blue/green though is being able to swap back to the other deployment if the new one fails. Well, you still have both 1.0 and 2.0 of FooType registered. So if your application started misbehaving after the upgrade from 1.0 to 2.0, you can just "upgrade" it back to 1.0! In fact, you can "upgrade" an application instance between as many different versions of its application type as you want! And you don't need to have instances of all your application versions running like you do in a swapping environment, you just have the different versions registered and a single application instance that can "upgrade" between versions.
I mentioned caveats with stateful services. The big thing to remember with stateful services is that the application state - your users' data - is contained in the application instance (fabric:/FooApp), so for your users to see their data you need to keep them on that instance. That's why we do rolling upgrades instead of deployment swaps.
This is just the basic idea. There are other ways you can play around with application types, versions, and instances depending on what your goals are and how your application works, but that's for another time.
Couchbase announced changes to CouchDB distribution:
http://blog.couchbase.com/couchbase-2011-year-review
CouchBase Single server has GeoCouch integration, is there an alternative to get GeoCouch support on CouchDB?
You don't have to use Couchbase for it. You can use GeoCouch with Apache CouchDB. It currently does on; work with CouchDB 1.1.x, but I'll update it to work with 1.2.x as well.
There is the refuge project, which is open source, has spatial search (fork of geocouch), based on CouchDB trunk, and maintained by one of the CouchDB contributors.
http://refuge.io/
https://github.com/refuge/refuge
Currently there is no 'binary' release, but I have found it very easy to build.
Hope that helps.