All,
as I am currently facing some load balancing and high availability
requirements regarding a WS-N implementation to be created (which will
have to provide a Web Services adapter/"profile" for existing JMS
destinations), I am looking for comments/best practices/input about
using Muse in a clustered environment:
By "clustered" environment I mean an environment that consists of two or
more "deployment units" (instances) of Muse within two or more instances
of an app server/web container (ideally stateless by itself, but using a
cluster-wide backing store for stateful data).
So the main question is: Is it possible at all/what does it take to add
clustering capabilities to a Muse (or Muse WS-N) deployment scenario?
(1) The two stateful entities that would have to be managed in a
cluster-complient way are
(1a) Subscriptions (implement NotificationProducerFilePersistence)
(1b) PullPointDatastores (implement PullPointDataStore)
But I doubt that (1a) and (1b) will be sufficient to create the same
notion of state within all instances at all times:
E.g. a NotificationConsumer freshly subscribes with cluster node 1 - how
would cluster node 2 be noticed about the state change (i.e. share the
state of the HashMap _subscriptionsByEPR of SimpleNotificationProducer)?
(2) Are there other issues or incompatibilities that - after having
implemented the management of state for (1a) and (1b) in a cluster-aware
way - would break a cluster deployment scenario?
Many thanks in advance for any comments, pointers or feedback!
Best regards,
Andreas
--
Andreas Loew
Java Architect
Sun Microsystems (Germany)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
