Home

News: ActiveCluster 1.0 Released

  1. ActiveCluster 1.0 Released (36 messages)

    Codehaus announced the 1.0 release of ActiveCluster, an open source cluster. This API enables developers to create high-availability clustered applications, similar in concept to the clustering capabilities used by commercial products such as WebSphere or Oracle.

    This release includes a complete core API and reference implementation, including the following features:

    • View the current nodes in the cluster and their state
    • Listen to nodes arrive, update their state, shut down or fail
    • Communicate with the cluster as a whole or with any specific node in the cluster
    • Elect a leader of the cluster to make decisions on behalf of the cluster
    Future versions will include more complex higher level protocols like buddy-group arrangement protocols and high-availability features.

    Check out ActiveCluster.

    Threaded Messages (36)

  2. ActiveCluster 1.0 Released[ Go to top ]

    Interesting, but does the open source community really need this? JavaGroups does this and more and probably has a lot of wrinkles worked out which are doubtless ahead for the team. We built our own (the HAManager) in WebSphere 6.0/5.1 XD and it takes a hugh amount of testing and domain knowledge to make these things work reliably.

    Billy
    IBM
  3. ActiveCluster 1.0 Released[ Go to top ]

    JavaGroups is LGPL while ActiveCluster is Apache 2.0 licensed. Not sure there is a single open source community. You have to take the license into account, especially when you reuse several open source projects in your own project.

    Thomas
  4. Thin JMS Wrapper?[ Go to top ]

    This clustering "framework" seems to be nothing more than a thin veneer around JMS. The ActiveCluster implementation does not include a full fledged clustering protocol, but rather, delegates all the "hard" problems (reliable group communication, etc.) to an underlying JMS provider.

    Furthermore, the API itself is tied to JMS, which seems to contradict the following from the ActiveCluster site:

    "It is easy to implement the ActiveCluster API on top of any networking library such as raw sockets, JMS, JGroups or Jabber. The default implementation uses JMS though we should be easily be able to add other implementations further down the line, like a JGroups implementation etc"

    In fact, the various ActiveCluster interfaces directly expose (and consume) JMS objects, so plugging in a non-JMS implementation doesn't seem feasible to me.

    Wouldn't this API be more useful if it tried to abstract away the underlying group communication mechanism?

    Jason Howes
  5. Thin JMS Wrapper? - Not really![ Go to top ]

    This clustering "framework" seems to be nothing more than a thin veneer around JMS.

    Not really - it provides a view of the nodes in a cluster, the ability to listen to nodes coming and going, viewing node state, leadership election and we're starting to add cluster group organisation policies.

    The ActiveCluster implementation does not include a full fledged clustering protocol, but rather, delegates all the "hard" problems (reliable group communication, etc.) to an underlying JMS provider.

    Huh? The current provider uses a JMS provider, sure. Note that ActiveCluster does not depend on reliable group communication - it could be layered on a pure multicast transport if you wanted.

    Furthermore, the API itself is tied to JMS, which seems to contradict the following from the ActiveCluster site:"It is easy to implement the ActiveCluster API on top of any networking library such as raw sockets, JMS, JGroups or Jabber. The default implementation uses JMS though we should be easily be able to add other implementations further down the line, like a JGroups implementation etc"In fact, the various ActiveCluster interfaces directly expose (and consume) JMS objects, so plugging in a non-JMS implementation doesn't seem feasible to me.Wouldn't this API be more useful if it tried to abstract away the underlying group communication mechanism?Jason Howes

    Go look again at the JMS interfaces we use in ActiveCluster - we use Message, Destination and MessageListener - all pretty trivial to implement on top of any transport mechanism.

    http://activecluster.codehaus.org/maven/apidocs/org/codehaus/activecluster/package-summary.html


    We could have made up some completely new interfaces - but reusing a few of the core JMS interfaces seemed the right thing to do since they are part of J2EE and how many interfaces do we need for Message and MessageListener anyways?.

    Note that the use of the JMS interfaces does not in any way depend on a full JMS provider.

    James
    Protique
    Enteprise Open Source
  6. Thin JMS Wrapper?[ Go to top ]

    The ActiveCluster implementation does not include a full fledged clustering protocol, but rather, delegates all the "hard" problems (reliable group communication, etc.) to an underlying JMS provider.

    You make it seem like a flaw to leverage J2EE infrastructure. I like that federation might not need obscure proprietary plumbing. Another more rattling implication of your point is that you're perhaps implying that JMS might not be up to the task.
  7. ActiveCluster 1.0 Released[ Go to top ]

    Interesting, but does the open source community really need this?

    Yes :)
    JavaGroups does this and more and probably has a lot of wrinkles worked out which are doubtless ahead for the team.

    Not really. There's no equivalent API available for clustering in JavaGroups last time we looked and JavaGroups is LGPL which is a no-no for lots of our users and customers.

    Even if JavaGroups was usable in the same way - that would make the API dependent on JavaGroups - rather than being able to work with existing messaging systems like Sonic, TibCo EMS/RV, MQSeries, ActiveMQ etc.

    We built our own (the HAManager) in WebSphere 6.0/5.1 XD and it takes a hugh amount of testing and domain knowledge to make these things work reliably.BillyIBM

    Agreed!

    James
    Protique
    Enteprise Open Source
  8. ActiveCluster 1.0 Released[ Go to top ]

    I find ActiveCluster an interesting approach to the clustering problem, beeing JMS based. Huge advantage and not really a "business" drawback since there are good and free jms providers out there.

    Can you elaborate on how content-based routing work? Can I route based on the content of my propriatary xml payload? Can I plug in routing logic based on *my* content structure?
    ...and JavaGroups is LGPL which is a no-no for lots of our users and customers.

    Why? Not that I don't believe you - I just don't understand why LGPL is a no-no. Enlighten me.

    Thanks.
  9. ActiveCluster 1.0 Released[ Go to top ]

    I find ActiveCluster an interesting approach to the clustering problem, beeing JMS based. Huge advantage and not really a "business" drawback since there are good and free jms providers out there.Can you elaborate on how content-based routing work? Can I route based on the content of my propriatary xml payload? Can I plug in routing logic based on *my* content structure?

    Sure - though thats more of an issue for pure JMS messaging rather than ActiveCluster per se.

    ...and JavaGroups is LGPL which is a no-no for lots of our users and customers.
    Why? Not that I don't believe you - I just don't understand why LGPL is a no-no. Enlighten me.Thanks.
    Apache open source projects cannot currently use any *GPL licenced open source projects - long story, try asking about it on an Apache mail list :). The short answer is the inability to reach clear and concise meaning of how *GPL licenced Java code can interact with the Apache/BSD licenced world without becoming virally affected.

    Also many users of open source are inside commercial organisations (end users, ISVs etc) and commercial organisations often prefer to keep away from *GPL licenses - whether its to avoid GPL viral infection or for legal issues.

    e.g. many large corporations have a list of approved open source licenses which have been passed through their legal team - the Apache license is always on there (so many folks use Tomcat / Ant etc) - but at least in my experience, *GPL licenses are rarely ever sanctioned.

    Note that the license is mostly an issue when you import code; so a *GPL licensed J2EE application server, such as JBoss is fine as you tend to use J2EE APIs rather than JBoss APIs when deploying your software - so possible viral infection is minimised - but for utility libraries, the *GPL license can often be an issue in large corporations (especially finance and telcos).

    Note that *GPL versus Apache licence can often be viewed as a religious and your mileage may vary on your company's licence restrictions/approvals.

    <ducks any *GPL jealots in this thread>

    James
    Protique
    Enteprise Open Source
  10. ActiveCluster 1.0 Released[ Go to top ]

    james you could also add, its a little harder for self-proclaimed 'experts' to make money off *GPL, .. where with the Apache license .. .. well .. i'll leave it to the intelligent reader and self-proclaimed 'experts'.
  11. ActiveCluster 1.0 Released[ Go to top ]

    james you could also add, its a little harder for self-proclaimed 'experts' to make money off *GPL, .. where with the Apache license .. .. well .. i'll leave it to the intelligent reader and self-proclaimed 'experts'.

    Huh?

    Doesn't JBoss make money of *GPL?

    The licence doesn't really affect the ability to offer professional services around the codebase - it just affects the abililty to use the code in commerical organisations.

    James
    Protique
    Enteprise Open Source
  12. ActiveCluster 1.0 Released[ Go to top ]

    I disagree, I'd be very surprised if what ever you're planning couldn't be implemented with a very thin layer on top of Javagroups or any VS messaging system. JavaGroups can have any transport, reliable or unreliable or JMS plugged in below it also so I don't buy that aspect either :)

    I still see little point in having yet another one. I think it has to be easier to get Bela to switch licenses than go through the pain of getting one of these things to work correctly. I predict someone making a very simple layer that will emulate your APIs on top of Java groups and it'll probably work now. This doesn't say Javagroups is perfect either but it's a lot further along.

    The focus on JMS in the thread is interesting. Any group services implementation needs to be built on top of a message transport. The problem with JMS is that the threading model is internalized in the provider and this can cause performance issues. Compare the JMS approach to something like the Tibco RV Java APIs to see what I mean. I'd have used an abstract interface rather than the JMS one for this reason. Plus, your performance is going to be poor compared with something with a specialized transport underneath.

    Billy
  13. ActiveCluster 1.0 Released[ Go to top ]

    I disagree, I'd be very surprised if what ever you're planning couldn't be implemented with a very thin layer on top of Javagroups or any VS messaging system.

    Sure - thats the whole point of the ActiveCluster API - to provide an abstraction on top of any transport - be it a JMS provider, JavaGroups, socket stuff etc. ActiveCluster is focussing on being an API with at least one provider - others can write new providers as/when necessary.

    JavaGroups can have any transport, reliable or unreliable or JMS plugged in below it also so I don't buy that aspect either :)I still see little point in having yet another one. I think it has to be easier to get Bela to switch licenses than go through the pain of getting one of these things to work correctly.

    Are you volunteering to convince Bela to switch to Apache 2.0 licence? :)

    I predict someone making a very simple layer that will emulate your APIs on top of Java groups and it'll probably work now.

    Or implementing the ActiveCluster API on top of JavaGroups, which is kinda the whole point :)

    BTW ActiveMQ has a transport for JavaGroups, so we can get ActiveCluster running on top of JavaGroups today with little overhead.

    If you're also volunteering to implement ActiveCluster purely on top of JavaGroups - heck go right ahead - thanks for volunteering Billy! :)

    This doesn't say Javagroups is perfect either but it's a lot further along.The focus on JMS in the thread is interesting. Any group services implementation needs to be built on top of a message transport. The problem with JMS is that the threading model is internalized in the provider and this can cause performance issues. Compare the JMS approach to something like the Tibco RV Java APIs to see what I mean. I'd have used an abstract interface rather than the JMS one for this reason.

    Note that ActiveCluster doesn't use any of the threading/connection/session interfaces from JMS so this is a non issue. We're just using the Message and MessageListener interfaces.

    Plus, your performance is going to be poor compared with something with a specialized transport underneath.Billy

    ActiveCluster can sit on any transport so again, this is a non issue. Also try out the performance of ActiveMQ versus JavaGroups - you might be pleasantly surprised.

    James
    Protique
    Enteprise Open Source
  14. ActiveCluster 1.0 Released[ Go to top ]

    Calling Java groups a message transport is like comparing a lighted match to a rocket engine. Most of the code that will be in ActiveCluster will be a dup of whats already in the Java groups synchrony related protocols. The message transport part is the easy bit.

    Javagroups provides all the services to pretty easily implement all the features of ActiveCluster with minimal coding. And no, I'm not volunteering ;)

    You missed my point on the threading, you are dependant on the threading model of the JMS provider you're using and that is an issue for very high performance stuff, the JMS vendor may not be using an optimal threading model for your purposes resulting in extra threads, locking or context switches.

    Happy Patricks day
    Billy
  15. ActiveCluster 1.0 Released[ Go to top ]

    Calling Java groups a message transport is like comparing a lighted match to a rocket engine. Most of the code that will be in ActiveCluster will be a dup of whats already in the Java groups synchrony related protocols.

    There's little code in ActiveCluster - its mostly an API.

    The message transport part is the easy bit.Javagroups provides all the services to pretty easily implement all the features of ActiveCluster with minimal coding.

    Sure. It should be fairly straightforward to implement the ActiveCluster API on JavaGroups - that's kinda the whole point!

    Though also remember people use other messaging systems than JavaGroups - so the default implementation sits on top of any JMS provider.

    And no, I'm not volunteering ;)You missed my point on the threading, you are dependant on the threading model of the JMS provider you're using and that is an issue for very high performance stuff, the JMS vendor may not be using an optimal threading model for your purposes resulting in extra threads, locking or context switches.Happy Patricks dayBilly

    I think you've missed my point too Billy :)

    ActiveCluster uses a few minimal interfaces from JMS / J2EE. It does not in any way depend on the threading model used by a JMS provider. So we could implement it directly on top of JavaGroups or TibCo RV pretty easilly. You could even invent your own new threading model and use that if you prefer.

    (As an aside you can use ActiveMQ in the same threading model as the RV threading model you mention).

    James
    Protique
    Enteprise Open Source
  16. ActiveCluster 1.0 Released[ Go to top ]

    JamesProtiqueEnteprise Open Source

    Just a little comment:
    If you are going to pimp your own company, you might want to spell the word "Enterprise" correctly. ;)
  17. ActiveCluster 1.0 Released[ Go to top ]

    JamesProtiqueEnteprise Open Source
    Just a little comment:If you are going to pimp your own company, you might want to spell the word "Enterprise" correctly. ;)

    LOL - thx :)

    James
    Protique
    Enterprise Open Source
  18. ActiveCluster 1.0 Released[ Go to top ]

    You missed my point on the threading, you are dependant on the threading model of the JMS provider you're using and that is an issue for very high performance stuff, the JMS vendor may not be using an optimal threading model for your purposes resulting in extra threads, locking or context switches.

    First you say that the customer requirements may include "very high performance stuff". But then you say that the customer may have chosen a suboptimal JMS vendor. This doesn't seem a valid scenario.
  19. ActiveCluster 1.0 Released[ Go to top ]

    First you say that the customer requirements may include "very high performance stuff". But then you say that the customer may have chosen a suboptimal JMS vendor. This doesn't seem a valid scenario.
    I think the point Billy is making is that an optimal JMS implementation - that is to say, a performant one, will not be as fast as a specialised "clusters`r`us" protocol.
    On the other hand it does not seem like a valid argument since apparently ActiveCluster has nothing to do with JMS except use a couple of interfaces, and provide a default implementation ontop of any JMS implementation.

    One thing that bit me when working with JMS was not being able to cleanly (meaning API-wise) obtain a reference to the Session that delivered the Message to my MessageListener. Since I need the session to control transactional flow and .acknowledge() is not enough, I really need the session, but there's no way of going up from MessageListener to the Session. Or am I missing something ? Cause if I don't this might bite ActiveCluster as well, from an API point of view.
  20. First you say that the customer requirements may include "very high performance stuff". But then you say that the customer may have chosen a suboptimal JMS vendor. This doesn't seem a valid scenario.
    I think the point Billy is making is that an optimal JMS implementation - that is to say, a performant one, will not be as fast as a specialised "clusters`r`us" protocol.On the other hand it does not seem like a valid argument since apparently ActiveCluster has nothing to do with JMS except use a couple of interfaces, and provide a default implementation ontop of any JMS implementation.One thing that bit me when working with JMS was not being able to cleanly (meaning API-wise) obtain a reference to the Session that delivered the Message to my MessageListener. Since I need the session to control transactional flow and .acknowledge() is not enough, I really need the session, but there's no way of going up from MessageListener to the Session. Or am I missing something ? Cause if I don't this might bite ActiveCluster as well, from an API point of view.

    This is a pure JMS question - the best way to solve this is to use a container which takes care of the transactions / acknowledgement for you. In J2EE thats a Message Driven Bean container. The downside of this is it means you're simple MessageListener POJOs now have to be fully fledged EJBs.

    If you don't want the overhead of a full EJB container (e.g. you're just using Tomcat) then you can use Message Driven POJOs instead using this Spring based Message Driven POJO engine which does the same thing

    http://activemq.org/JCA+Container

    The container takes care of the thread pooling, connection/session pooling and transaction/acknowledegment handling for you - all you need to do is write a MessageListener POJO and you can let Spring do all the dependency injection stuff for you (injecting database connection pools and the like into your POJO)

    James
    Protique
    Enterprise Open Source
  21. ActiveCluster 1.0 Released[ Go to top ]

    If only things were so simple James. For simple apps, you're right. For complex ones, well, it just doesn't work.

    If the container supports the pattern your application needs then fine if not then ouch. It's why we added async beans APIs to WebSphere. They are now present in the base application server on 6.0 BTW. It lets the application makes it's own threads that work in conjunction with the J2EE runtime. A synergy that lets WebSphere be used for applications which don't map well on to the 'simple' J2EE container models as well an apps that need a different sort of container in terms of implementation.

    Customers have already resorted to a J2SE environment for these types of applications because of such limitations. Async beans lets them leverage the investment they made in WebSphere and that we made in our runtime for these applications.

    Why would an application needs this? Suppose you had an application that needed to change the set of JMS destinations it pulled messages from while it was running, i.e. it didn't run in a static environment. Would the MDB container be the best way to solve this? Another example is an application with special request sequencing for incoming work. Can't do that also with a normal J2EE container. People will tell u "Use JMS" etc but performance wise such "best practises" (sometimes it is a dirty word) are just aweful when a hundred or so lines of Java with your own threading achieves what you wanted with much better performance.

    These examples are just the tip of the iceberg. If the container supports the pattern you want, then as I said, cool. Otherwise, it's just frustrating. I prefer not to be frustrated :)

    The alternative to async beans is to write your own JCA RA and try to integrate it with your app which can use the J2EE runtime using MDBs. If people complained about EJBs being awkward, wait till they try this...

    4am, time for bed :P

    Billy
  22. ActiveCluster 1.0 Released[ Go to top ]

    Suppose you had an application that needed to change the set of JMS destinations it pulled messages from while it was running, i.e. it didn't run in a static environment. Would the MDB container be the best way to solve this? Another example is an application with special request sequencing for incoming work. Can't do that also with a normal J2EE container.

    Obviously this problem of amorphous topology has nothing to do specifically with JMS or asynchronous messaging. Any J2EE, distributed program, or fat client could potentially be deployed in an amorphously federated environment. If anything ActiveCluster's monitoring API is likely a big part of the solution to the problem you've posed.
  23. ActiveCluster 1.0 Released[ Go to top ]

    Or just use WebSphere XD. It has dynamic highly available J2EE singleton support along with fully supported threading with async beans so basically your imagination is the limit on terms of what can be built on a supported industry runtime.

    The WebSphere Partition Facility (part of XD) adds fully integrated support for a dynamic set of routable named singletons to J2EE applications. Customers are using this to build electronic trading systems, computational grid applications, batch processing and other similar systems.

    Billy
  24. First off, thanks for the reply.
    I've had a really hard time reading it though, the abundance of POJOs turns my stomach.

    Yes, this is a pure JMS question - the idea was that your use of MessageListener would lead to the problem I've described.

    I'm not sure we're on the same level here; let me clarify.
    The system uses JMS to split work between system parts and messages carry task parameters. The front-end creates "jobs" that are carried out by another system component. These jobs involve remote systems and in case they were completed (not necesarily having produced a satisfactory answer, but merele a complete one) a database needs updating, else not.
    Messages are enqueued with CLIENT_ACKNOWLEDGE.
    If the consumer failed while trying to execute the job the message must not be consumed/acknowledged, in order to leave the message/job available.
    Problem is when you acknowledge a message all previously un-acknowledged messages will also get ACK-ed. Definitely not I want. Therefore from the MessageListener implementation class (it's a class, not an object definitely not a ... puah... POJO) I _need_ to have access to the session so as to be able to commit() and rollback() at will. And I do, by "injecting" (thundering applause from the IOC crowd) the session into the consumer in the constructor.

    Now if I read your answer correctly the only clean and pre-made way to have access to commit and rollback is to turn the consumer into a MDB as that provides transactional support in addition to the MessageListener interface.

    If that's the case I guess someone should have put a bit more thought into the API in the first place.

    Another alternative would also be to loop forever polling for messages - the session is already at hand. Is this smarter ?

    FWIW I'm testing on Oracle AQ.
  25. First off, thanks for the reply.I've had a really hard time reading it though, the abundance of POJOs turns my stomach.Yes, this is a pure JMS question - the idea was that your use of MessageListener would lead to the problem I've described.I'm not sure we're on the same level here; let me clarify.The system uses JMS to split work between system parts and messages carry task parameters. The front-end creates "jobs" that are carried out by another system component. These jobs involve remote systems and in case they were completed (not necesarily having produced a satisfactory answer, but merele a complete one) a database needs updating, else not.Messages are enqueued with CLIENT_ACKNOWLEDGE.If the consumer failed while trying to execute the job the message must not be consumed/acknowledged, in order to leave the message/job available.Problem is when you acknowledge a message all previously un-acknowledged messages will also get ACK-ed. Definitely not I want. Therefore from the MessageListener implementation class (it's a class, not an object definitely not a ... puah... POJO) I _need_ to have access to the session so as to be able to commit() and rollback() at will. And I do, by "injecting" (thundering applause from the IOC crowd) the session into the consumer in the constructor.Now if I read your answer correctly the only clean and pre-made way to have access to commit and rollback is to turn the consumer into a MDB as that provides transactional support in addition to the MessageListener interface.If that's the case I guess someone should have put a bit more thought into the API in the first place.Another alternative would also be to loop forever polling for messages - the session is already at hand. Is this smarter ?FWIW I'm testing on Oracle AQ.

    You can if you wish use IoC to inject the Session into your MessageListener implementation (you obviously don't like the term POJO so I'll refrain from using it :).

    However for consuming messages, you often need to perform connection, session and thread pooling to control how concurrent you want to process messages and to perform high throughput consumption from JMS in an efficient way. Also you may want to take advantage of a container's ability to handle dead letter queues and so forth.

    So while your hand-crafted way of using a Sesssion in your MessageListener will work, I would advise either using MDBs or Message Driven POJOs as it simplifies your code and lets the container perform more efficient JMS consumption on your behalf.

    James
    Protique
    Enterprise Open Source
  26. (you obviously don't like the term POJO so I'll refrain from using it :)
    I would advise either using MDBs or Message Driven POJOs as it simplifies your code and lets the container perform more efficient JMS consumption on your behalf.

    Ah, got you, James: You just couldn't refrain from saying POJO :-)

    Juergen
  27. ActiveCluster 1.0 Released[ Go to top ]

    I'd have used an abstract interface rather than the JMS one for this reason. Plus, your performance is going to be poor compared with something with a specialized transport underneath.Billy

    Billy, I just don't buy into what you're saying. JMS is an interface, and it can be implemented to optionally have a threading model like RV's.

    I certainly think the poor performance argument is totally off, there are a lot of JMS providers who will provide better performance than Javagroups as well a provide an optionally better QoS as well.

    Rob Davies
    SpiritSoft
  28. ActiveCluster 1.0 Released[ Go to top ]

    The deal here is basically this. The Tibco pattern externalizes the threading model. They have a memory queue on to which, events from the messaging system are dropped. The application makes it's own thread and then calls dispatch on the queue. The dispatch method appears to simply invoke callbacks for the various events types on the queue using the thread that dispatch was invoked on. The application can dispatch events one by one or dispatch events for some period of time.

    This approach rather than the JMS one where the JMS provider owns the threads is more flexible in certain situations particularly when dealing with event sequencing. I'm not saying these scenarios can't be done with JMS, just that the model above is more flexible in that the customer can do anything it wants threading wise. JMS requires a thread per session unless you poll the destinations which is hardly a choice alternative anyway as the thread gets dedicated to a particular destination and is wasted most of the time.

    It just a different philosophy on the way both were designed. Personally, being the guy that I am, I like the Tibco approach as it's more flexible, i.e. I can do what I want. I'm more constrained with the JMS model. You're right, that it could be implemented to have a different threading model, it's just that the customer can't do it, the JMS vendor does it. Thats the difference. If what you have doesn't quite suit, I'm stuck with it. I'm not with the RV API pattern. It's flexibility.

    Poor performance is all relative. A native socket based implementation has less path length then a generic one and the interfaces can be optimized to suit the purpose. It's going to be faster in terms of ops/sec because of the shorter path length. I never said Javagroups was faster and before Bela comes on and pounds me, I didn't say it was slow either :)

    Billy
  29. From Active Cluster website:
    Its very easy to implement ActiveCluster on top of any messaging or networking technology. The default implementation out of the box uses JMS.

    When I looked at the API, Cluster interface has the following methods:
    javax.jms.MessageConsumer createConsumer(Destination destination);
    javax.jms.BytesMessage createBytesMessage();
    ...

    Seems like the notion of JMS is deeply embedded into API.
    It would pretty much be impossible to port this API to any protocol other than JMS.

    Why should I even install JMS to cluster my application to begin with?

    The only information the Node interface gives is the name of the node. What about operating system, number of CPUs, load, available memory, etc...?

    This looks like yet another under-thought Open Source toy.

    --Dmitriy.
  30. ActiveCluster 1.0 Released[ Go to top ]

    From Active Cluster website:
    Its very easy to implement ActiveCluster on top of any messaging or networking technology. The default implementation out of the box uses JMS.
    When I looked at the API, Cluster interface has the following methods:
    javax.jms.MessageConsumer createConsumer(Destination destination);javax.jms.BytesMessage createBytesMessage();...
    Seems like the notion of JMS is deeply embedded into API.It would pretty much be impossible to port this API to any protocol other than JMS.

    We resuse the MessageConsumer interface which is very trivial to implement...

    http://java.sun.com/j2ee/1.4/docs/api/javax/jms/MessageConsumer.html

    along with the core JMS Message interfaces - again, trivial POJOs to write. These are simple to use with any transport.

    Why should I even install JMS to cluster my application to begin with?

    Its fairly easy to implement these core JMS interfaces on top of any transport. You could use ActiveMQ on top of multicast for example which is just a couple of JARs and doesn't require a full 'install'.

    FWIW we've found this library invaluable in various projects such as Geronimo, ActiveMQ and WADI.
    The only information the Node interface gives is the name of the node.

    Take a closer look...

    http://activecluster.codehaus.org/maven/apidocs/org/codehaus/activecluster/Node.html

    a Node can have an arbitrary amount of local state associated with it such as...
    What about operating system, number of CPUs, load, available memory, etc...?

    All the above is easily possible. A node can decide what state to expose to other members of the cluster.
    This looks like yet another under-thought Open Source toy.--Dmitriy.

    I'm sorry you feel that way Dmitriy - maybe if you took a closer look at it and saw where it was used you might change your mind.

    But certainly ActiveCluster is a fairly low level library and not intended for everyone to use - its more for middleware services like HA, message brokers, distributed session state systems etc

    James
    Protique
    Enteprise Open Source
  31. ActiveCluster 1.0 Released[ Go to top ]

    We resuse the MessageConsumer interface which is very trivial to implement...

    http://java.sun.com/j2ee/1.4/docs/api/javax/jms/MessageConsumer.html

    along with the core JMS Message interfaces - again, trivial POJOs to write. These are simple to use with any transport.

    I can't even begin to explain how wrong this design desicion is.

    The correct way would be to create your own set of interfaces and have a JMS implementation for it.
    Its fairly easy to implement these core JMS interfaces on top of any transport. You could use ActiveMQ on top of multicast for example which is just a couple of JARs and doesn't require a full 'install'.

    Why JMS? You should be protocol independent, which should also mean JMS-API independent. You just poluted your API with JMS protocol specifics and are forcing other protocols to implement JMS API.

    This is just a very poor API design.

    --Dmitriy.
  32. ActiveCluster 1.0 Released[ Go to top ]

    We resuse the MessageConsumer interface which is very trivial to implement...http://java.sun.com/j2ee/1.4/docs/api/javax/jms/MessageConsumer.htmlalong with the core JMS Message interfaces - again, trivial POJOs to write. These are simple to use with any transport.
    I can't even begin to explain how wrong this design desicion is.The correct way would be to create your own set of interfaces and have a JMS implementation for it.
    Its fairly easy to implement these core JMS interfaces on top of any transport. You could use ActiveMQ on top of multicast for example which is just a couple of JARs and doesn't require a full 'install'.
    Why JMS? You should be protocol independent, which should also mean JMS-API independent. You just poluted your API with JMS protocol specifics and are forcing other protocols to implement JMS API. This is just a very poor API design.--Dmitriy.

    The interfaces we used were for Message and MessageListener. We absolutely could have created our own versions of these interfaces that were different from the J2EE standard ones - it just seemed silly to redefine them for the sake of it.

    e.g. why can't I use a standard JMS MessageListener to process cluster messages?

    You're absolutely welcome to your opinion of course, but the decision we made some time ago was to reuse a few trivial interfaces from J2EE to lower the learning curve & promote reuse with J2EE.

    Note - the fact that we reuse a few trivial interfaces from the JMS API does not force ActiveCluster to be JMS dependant, we don't force other protocols to implement JMS or in any way affect the protocols it uses. Really - go look at the JMS interfaces we use - they're trivial to implement on other protocols.

    James
    Protique
    Enterprise Open Source
  33. Laughable[ Go to top ]

    It seems that that some very stubborn people are upset that you chose to provide a default implementation. These are the same people who would pitch a fit in grade school when someone brought in a stick of gum for their best friend and not the rest of the class. Boo hoo.

    Perhaps, next time, this will be a lesson to not provide a default implementation or else provide one for every transport! :) Unfortunately, it seems that you needed to actually use this API in a lot of quality opensource software products.
  34. ActiveCluster 1.0 Released[ Go to top ]

    Dmitry said:
    Why should I even install JMS to cluster my application to begin with?

    It actually makes a lot of sense ot me, because JMS provides standard solutions to a lot of the "hard" problems a clustering solutions must necessarily deal with. This also mean I can leverage whatever JMS infrastructure I have.

    I can't see why depending on JMS (a standard) beeing problem. Better than depending on non-standard stuff like JavaGroups.

    IMHO ;-)
  35. ActiveCluster 1.0 Released[ Go to top ]

    JMS-reliance seems rather strange… Anyways, for a full-fledge cluster support for Java look at Fitech Labs’s xTier/CLUSTER product at http://www.fitechlabs.com/products_xtier_services.jsp#xtier_cluster.

    It is not OS but functionally much more superior.

    Regards,
    Nikita Ivanov.
    nivanov at fitechlabs dot com
  36. ActiveCluster 1.0 Released[ Go to top ]

    basically ...

    - protique wanted something else to make money off as they spotted that there are idiots who make decision (this includes protique 'themselves')
    - in not too many words, they wanted to do a 'core developers' thing and rival jgroups, etc.

    IF they provide a fully fledged 'raw' socket implementation, then maybe, it can be called a framework.

    This is what will happen, ... it will basically stay ontop of jms, ... this is why i'd call this 'a micky mouse framework' capitalising on stupidity within the industry.
  37. AMQ[ Go to top ]

    http://www.eweek.com/article2/0,1759,1761537,00.asp

    "Features of the proposed AMQ transport technology:
    # Reliable implementations on C and C++
    # Support for C# and Java
    # Transactional, point-to-point, publish-and-subscribe model
    # Simultaneous support for 100MB data chunks and market feeds
    # IM built into the OS kernel"

    Wow !

    About ActiveCluster, probally I will never have a change to use it (at least for the kind of projects i have been working), but reading it´s javadocs was a pleasant experience, anybody who read and understand it can have an pretty idea of a cluster system semantic and it is great !

    OSS is about it: freedom. It keep pushing us forward.