[axon-hazelcast] Code review/comment/everithing-else

Imported from Google Groups
#1

Hi all,
since some weeks I’m working on Hazelcast-AxonFramework (https://github.com/lburgazzoli/lb-axon) and as today my focus is on an implementation of the EventBusTerminal interface based on Hazelcast’s Topics (http://www.hazelcast.com/docs/2.6/manual/single_html/#Topic).

The code is far to production quality and it lacks documentation, test cases and so on but I would love to have some feedback/criticism from you guys.

The relevant packages are:

  • org.axonframework.hazelcast

  • org.axonframework.hazelcast.eventhandling

  • org.axonframework.hazelcast.eventhandling.impl

  • org.axonframework.hazelcast.samples
    The class implementing the EventBusTerminal is HazelcastEventBusTerminal and it is not suppose to directly broadcast events locally but it relies on Hazelcast publish/subscribe “engine”.
    The implementation needs two additional object to properly publish/subscribe events:

  • IHazelcastTopicPublisher.java

  • IHazelcastTopicSubscriber.java
    Why? Because you can split the workload across different Hazelcast-Axon nodes without having all your nodes processing unwanted events.

IHazelcastTopicPublisher has some default implementations that let you to choose the topic to send an event to based on the class name, the package name or the default one:

IHazelcastTopicSubscriber has a couple of default implementations to subscribe to a predefined topics or to the topics that match a pattern:

#2

Hi,

We are considering adopting Hazelcast as our distributed computing middleware, if it can also support the distributed parts of Axon. So I would very much like to hear, how far you have come, with your implementation - is there anything missing? And if you have experienced any problems?

Our motive for looking at Hazelcast is, that the application needs to run on Amazon EC2, which does not support multi-casting, and running JGroups with TCP-based discovery significantly more cumbersome than using the Hazelcast EC2 auto-discovery.

Thanks in advance,
Thomas

#3

Hi,
the thing is that this project is something I work on in my spare time so yes I have experienced quite a few problems :slight_smile:

What has been implemented so far:

  • distributed queue based connector
  • distributed executor based connector
  • distributed event store (for event sourcing)
  • distributed event bus

What is missing(at least as per my plans) is support for Hazelcast as JCache implementation (but it will come for free in the future thx to the hazelcast-jcache implementation.) and a saga repository. It also lacks a robust error handling.

What I think is really promising is the distributed executor based connector as it let you to scale your system by cloning a node.

My goal is to make it production ready and then put it under AxonFramework umbrella so I’d more than happy to receive feedback, bug reports and contributions.

Luca

#4

Hi,

Possibly, I can get to spend some of my work-time on it. :slight_smile:

Does any of the problems indicate that Hazelcast is not suitable as the transport layer for distributed event and command buses? (We are not currently concerned about using truly distributed event stores.)

I have played a bit around with the code, and there are some components, which I don’t quite understand the purpose of, so I hoped, you could help me out:

  • What exact role does the HzAxonEngine play? It contains references to a lot of different system parts, to which it in most cases just delegates its methods. On the face of it, it seems to me, that this functionality belongs in the respective components.
  • Under somewhat the same topic, I think HzProxy rather than having its own type (IHzProxy) should simply wrap a HazelcastInstance (decorator pattern). In that way, users only get functionality, they need/want. I for one, does not understand, what it is, the current proxy adds. There is some stuff about prefixes (which in my my should be in a “PrefixDecorator”). Then there is the nodeName, which I cannot quite tell how differs from the HazelcastInstance.name? (At least in my toy-example, they are the same.) Finally, there is convenience method for shutting down the Hazelcast instance.

Thanks,
Thomas

#5

Hi,
this is a great news for me.

Then:

  • Most of the problem were related to wrong assumption I made about Axon because of a limited knowledge I had at the time I started the project. As today I have not experienced problems related to Hazelcast as transport layer
  • HzAxonEngine should be moved in axon-samples and the role is just as helper/sample to show a possible way to set-up a node to be used with distributed executor service, it is similar to SampleApp
  • HxProxy is now less useful than some time ago when it was used primary as workaround for Hazelcast problems in OSGi (solved by HZ 3.x) so I agree that it can be refactored; I do not remember why there is a nodeName method and I guess you’ll find some other unclear thing about nodeName and clusterName, it is something I need to refactor/tidy-up

Luca