On Tue, Sep 16, 2008 at 12:36 PM, Anne Noseda <[EMAIL PROTECTED]> wrote: > >>>>>>> - 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 ?
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-tp19254179p19509261.html > Sent from the ServiceMix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
