> My initial thought had been to simply run the application backend on large > servers with an embedded HA setup, but further examination of the > deployment process has led me to conclude that this won't support a rapid, > reliable upgrade cycle, since it will be too ___expensive to bounce the > embedded instances.___ > > What do you mean by this? Neo4j's HA cluster supports rolling upgrades and > restarts. >
I'm not attempting to use a live-update mechanism such as OSGi, instead going ahead and just restarting the entire Spring context for updates. In the traditional relational case where you have a business-tier server with your application logic (and maybe HTML/JSON, or maybe that's on another tier) and a database tier, restarting instances in the business tier is a rather trivial matter of course, since the database just keeps chugging along on the backend unless it needs major maintenance itself (like maybe a disk-format upgrade). Additionally, starting and stopping the business tier is completely independent from the database tier, and there's no need for fine-grained coordination when handling a rolling restart. With an embedded database, however, restarting the Spring context (which might happen several times a day in the case of continuous deployment) requires restarting the database server, including synchronization with the rest of the cluster, and a rolling restart requires ensuring that the current master is completely replicated before restarting it. The actual difficulty here is, of course, largely dependent on how long synchronization takes for a very large data set under a significant load; does Neo have data on this issue? I'd be very interested in dreaming about a more full-featured server-plugin architecture, perhaps one more like the traditional servlet model where you can undeploy and redeploy applications without restarting the container itself. I looked into the server-extension options as of 1.9, but they didn't seem to fit the usual Spring application model well, and I didn't see anything about major changes there for 2.x. I remember that there was discussion of development of a more efficient > network API for accessing external instances using the Java API and SDN; is > this something that's on the roadmap? > > This is still on the roadmap but not in the next release afaik. > > The fine grained operations that SDN currently relies on, will never work > well over the wire. So rewriting SDN to use a cypher-driver based ORM under > the hood is part of that equation. Then in the driver the protocol can be > adapted. > Is this because of lazy-loaded data out of the mmapped region? -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
