Event Queues in a Clustered Environment

asked 2012-01-13 22:35:43 +0800

mkamm gravatar image mkamm

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?


Mark K

delete flag offensive retag edit

18 Replies

Sort by ยป oldest newest

answered 2012-02-14 10:05:34 +0800

afxgroup gravatar image afxgroup
126 1

no.. simply, plain java+zk

link publish delete flag offensive edit

answered 2012-02-24 08:26:38 +0800

gekkio gravatar image gekkio flag of Finland
899 1

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 :)

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

link publish delete flag offensive edit

answered 2012-02-24 15:45:37 +0800

afxgroup gravatar image afxgroup
126 1

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

link publish delete flag offensive edit

answered 2012-02-24 20:34:02 +0800

terrytornado gravatar image terrytornado flag of Germany
9393 3 7 16

many thanks to gekkio and afxgroup..

I'm interested in both codes. :-)
Seems that ZooKeeper is used in many server applications.


link publish delete flag offensive edit

answered 2012-02-28 10:45:01 +0800

gekkio gravatar image gekkio flag of Finland
899 1

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!

Source code


Later on I'll create a sample app and post a short tutorial to my blog.

link publish delete flag offensive edit

answered 2012-02-28 20:12:30 +0800

terrytornado gravatar image terrytornado flag of Germany
9393 3 7 16

updated 2012-02-28 20:13:02 +0800

Absolute great news Joonas. Many many thanks for spending time on this.

I'll have a look on it asap.


link publish delete flag offensive edit

answered 2012-04-07 08:54:52 +0800

simonmassey gravatar image simonmassey
90 1

updated 2012-04-07 09:02:27 +0800

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.

link publish delete flag offensive edit

answered 2012-04-07 11:22:24 +0800

afxgroup gravatar image afxgroup
126 1

I can assure you that in our cluster of 7 machines the solution i've implemented is really robust.
Actually I never loose a single message and all is implemented with a simply servlet call.

link publish delete flag offensive edit
Your reply
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

[hide preview]

Question tools




Asked: 2012-01-13 22:35:43 +0800

Seen: 551 times

Last updated: Apr 07 '12

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More