Hello, To continue our previous discussion about the clustering feature which is missing in the wsn-component :
- I've tried to use the same subscription ID for 2 different subscribers but it doesn't work : only one subscriber can be alive at one time. Then the other can resume the subscription but they cannot be alive in the same time. So, if we choose this way to resolve the duplication of notification, we must code a system to know when one instance of Servicemix is down and to resume the subscription on another instance ... it seems to be very complex - So I've tried the second solution : virtual topic. I've only tested with one instance but it seems to work very well so I will continue in this way. - For the administrative topic, in which we will post all the subscriptions and registrations requests to warn all the Servicemix instances, where do you think it must be implement ? I hesitate between the "doInit()" method of the "org.apache.servicemix.wsn.component.WSNLifeCycle" class or the "init()" method of the "org.apache.servicemix.wsn.jms.JmsNotificationBroker" class. Thanks in advance, Anne. ++++++++++ PREVIOUS DISCUSSION +++++++++++++++++++++++++ >>>>>>> - what about clustering ? I see that if we have two endpoints >>>>>>> clustered, >>>>>>> they will receive two notifications. But I see also you open a JIRA >>>>>>> for >>>>>>> it >>>>>>> (https://issues.apache.org/activemq/browse/SM-418) where you say >>>>>>> that >>>>>>> durable subscription can correct it ? > >>>>>> I think there are two disctincts use case here. If a subscriber is >>>>>> a >>>>>> JBI endpoints (deployed in a service unit for example), this endpoint >>>>>> may exist in several servicemix instances in the cluster. So they >>>>>> should act as a *single* subscriber and not receive multiple copies >>>>>> of >>>>>> the same notification. > >>>>> So, it is an improvment done recently ? Because on your website, you >>>>> write : >>>>> " >>>>> The current implementation has several limitations: >>>>> * subscriptions can not be clustered: if you register the same >>>>> subscriber in a cluster, each node will receive all notifications >>>>> " > >>>> No, and that's the problem. They *should* act as a single subscriber, >>>> but it does not work this way at the moment. > >>> Ok, but have you an idea how to correct this ? I have one but I don't >>> know >>> if it is the best ... maybe you have a best way to correct that. My idea >>> is >>> the following : >>> 1. when the servicemix instance receives the JMS notifications from the >>> topic, it tries to write the JMSMessageID property in a DB table (INSERT >>> operation, ID is the unique column and the primary key) >>> 2. if it succeed, the servicemix instance sends the notification >>> 3. if it fails, the servicemix instance don't send the notification >>> (writes >>> a log for example) > >> Using durable subscriptions would work. If two JMS consumers have the >> same durable subscription id, only one of them will receive a given >> message afaik. >> We may also want to leverage ActiveMQ virtual destinations instead. >> See http://activemq.apache.org/virtual-destinations.html for more >> informations. > > About virtual destinations : > - isn't it too specific to ActiveMQ broker ? > - if I have well understood the concept, the topic is virtual and for each > subscriber, one physical queue is created : will the notifications be > duplicated in all these queues for each subscriber ? if yes, isn't it too > expansive in term of time and place ? « [hide part of quote] We may be able to find a way to do both by adding a configuration flag on the component. >>> Another point, when an external subscriber sends a subscription message, >>> this message will be oriented (by an alteon) to one servicemix instance. >>> This instance will create the JBI endpoint only on this instance or also >>> on >>> all the servicemix instances in the cluster ??? >>> Same question for registration of publishers. > > You didn't reply ... I missed that one. Currently, the WS-Notification components have no knowledge of clustering, so the subscription / publisher is only valid for the component that received the request. At some point in the discussion, we talked about persisting this data in a database, but it would only work across restart of a single component. If you need full failover, it means that when a component receives a subscription or registration, it has to inform the other components to do so too. I guess we could have a topic for that where all components would subscribe to and which would be use to send commands to other components. At some point for such a system, I guess we might want to use transactions too... -- View this message in context: http://www.nabble.com/WS-Notification-Component-Improvment---Clustering-tp20555931p20555931.html Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
