Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
Hi All,
I have read a bunch of the documentation, specifically the ZK 5.0.9 Developers Reference. The Event Queue is a really nice feature. One thing I am not really clear on and I would like to know before I go down this path...
Can we use Event Queue at an application level in a Clustered Environment?
Thanks
Mark K
Afxgroup's solution sounds decent, but typically these kind of things are done with publish-subscribe messaging just like Stephan speculated in his comment.
Having a separate messaging server (or multiple servers) makes things easier, because the application servers do not need to communicate with each other. Another solution is to use some kind of clustering library, such as JGroups but implementing such a solution is pretty complex. JGroups also has some problems in large clusters, so most people use today ZooKeeper for basic clustering needs.
If you use Weblogic, a common way is to use JMS and the underlying messaging system of Weblogic, but personally I'm a fan of more lighter solutions such as AMQP-based products. I've used AMQP with RabbitMQ in production before, and I've had no problems with it.
My recommendation is to install a separate RabbitMQ server, and write a lightweight communication bridge between AMQP and the application level event queue.
This is a very interesting problem, so I might implement this myself at some point...stay tuned :)
Glossary:
JMS: Java Messaging System. Standard Java EE API for messaging.
AMQP: Advanced Messaging Queue Protocol. A protocol for messaging middleware
RabbitMQ: Erlang-based messaging server that implements AMQP 0.9
ZooKeeper: Library for coordination of distributed servers
JGroups: Multicast communication library
Well, actually the process is working well on 10 load balanced servers.. the messages are dispatched almost istantly. I've also successfully find a procedure to unsubscribe the page from the queue just implementing a finalize method in my class.
Maybe there are other ways to do this but i think that sometimes simply solutions are not always the worst one.. :D
many thanks to gekkio and afxgroup..
I'm interested in both codes. :-)
Seems that ZooKeeper is used in many server applications.
thx
Stephan
I spent some fun time with RabbitMQ and implemented the bridge module :)
I've published it in my open source jawwa -project, so it's easy to include it in projects that use dependency management (e.g. Maven).
Note that this is mostly an experimental proof-of-concept module and has not been used in production!
Later on I'll create a sample app and post a short tutorial to my blog.
Absolute great news Joonas. Many many thanks for spending time on this.
I'll have a look on it asap.
thx
Stephan
Looking at the documentation of EventQueue and reading its description of synchronous event queues, which are safe to manipulate desktop components, they appear the perfect solution for in-memory gui eventing within a complex desktop for a given user.
If someone has a complex desktop with many screens and controllers wanting to do Observer Pattern then this is great support to update different areas of many screens with out having to link them together in code (the only have to listen to the event queue). The ability to use them in a clustered environment (e.g. serializable) means that they wont cause crashes when you failover in a cluster.
The concept of an asynchronous EventQueue seems a different use case, with a separate thread and automatic server push. It is not allowed to access any Component so it cannot update the screen. It can only do business work then notify that it is finished. The description in Long Operations shows it used as an asynchronous callback which cannot update the screen which then pushes to a sychronous queue to do the screen update. In effect it solves the problem of having to program your own polling mechanism. For example we had document rendering which could take up to a dozen seconds at peak times so we implemented our own Timer mechanism to poll. That would be easy to replace with a desktop event queue. Of course if the thread is running in one node of a cluster, and that node crashes, then the asynchronous work is lost.
The idea of using an application scoped EventQueue to do global eventing seems an idea with a lot of complication. If you are in a clustered environment with many nodes there are many application scopes. Java and J2EE does a lot to distance a developer from the physical setup. To join all the servers together requires something else. It would seem wise to choose a messaging server product to fulfil this requirement. The documentation hints at this with its custom scopes example in Extend Event Queue which hints at a jms scope. Putting in a RabbitMQ server and wrapping that as an EventQueue could give you the benefit of bridging messages into the desktop like the long running example.
Making that work in a clustered environment should not be hard. How it behaves when one node fails in the cluster will be a unique set of problems when the user session/desktop fails-over. Personally I don't see trying to get failover to be transparent to the user is cost effective. The average users browser crashes more often than we ever get server crashes. When their browser crashes they have to log back in again; having them do that for a server crash which we have never encountered seems satisfactory.
Asked: 2012-01-13 22:35:43 +0800
Seen: 551 times
Last updated: Apr 07 '12
