You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by rotgier <ro...@gmail.com> on 2009/06/01 09:00:59 UTC
How to turn off DONE messages
Hello,
is there a possibility in SMX4 to turn off sending DONE messages? If so,
then how to do it?
Kind Regards,
Marek Psiuk
--
View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810732.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: How to turn off DONE messages
Posted by Adrian Trenaman <tr...@progress.com>.
Thanks for the clarification Guillaume!
Best,
Ade.
Guillaume Nodet wrote:
> Well, it's not really turning OFF done messages. Those are mandatory
> from a spec pov but also from an implementation pov, else you could
> end up with lots of threads waiting forever (this is a common mistake
> for new users dealing with the JBI api).
>
> If you use the Smx4 cluster engine, the default behavior is configured
> so that the DONE messages will not end up being sent as JMS messages.
> Actually, the behavior is controlled by the
> <code>rollbackOnErrors</code> flag. If this flag is set and the
> transaction model is not <code>None</code>, any exchange that comes
> back in an <code>Error</code> status will lead to the transaction
> being rolled back (or the ack not sent). This also means that no
> error status can be conveyed back to the original exchange.
>
> So it's a bit more tricky then simply saying you don't need the DONE
> message, because either the consumer expects a response or it does
> not. So for an InOnly mep, either the client will wait for a response
> which will be either a DONE or ERROR message, or it does not, and if
> there is an error, the transaction (if any) will be rolled back by the
> cluster engine on the provider side.
>
> 2009/6/1 rotgier <ro...@gmail.com>:
>
>> Hmm,
>>
>> then what does Adrian Trenaman ment saying here:
>> http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
>> that "you can now optimize the JBI messaging layer to omit the use of JBI
>> DONE messages: so, if you're implementing a one-way interaction over the JMS
>> flow, you don't end up having to deal with an DONE that you simply don't
>> need" ?
>>
>> Kind Regards,
>>
>> Marek Psiuk
>>
>>
>> Freeman Fang wrote:
>>
>>> Hi,
>>> No, I don't think so.
>>> As MEP (message exchage pattern) defined in JBI spec all ends with DONE
>>> message, it's required by the JBI spec.
>>> Freeman
>>>
>>>
>>> rotgier wrote:
>>>
>>>> Hello,
>>>>
>>>> is there a possibility in SMX4 to turn off sending DONE messages? If so,
>>>> then how to do it?
>>>>
>>>> Kind Regards,
>>>>
>>>> Marek Psiuk
>>>>
>>>>
>>> --
>>> Freeman Fang
>>> ------------------------
>>> Open Source SOA: http://fusesource.com
>>>
>>>
>>>
>>>
>> --
>> View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>>
>
>
>
>
Re: How to turn off DONE messages
Posted by Guillaume Nodet <gn...@gmail.com>.
There is an incompatibility between the spring-dm version provided by
the kernel (1.2.0-m2) and the one request by the nmr (1.2.0-rc1).
You might work around the problem by upgrading the spring-dm version
used by the kernel or downgrading the one used by the nmr and
rebuilding.
Actually, a better fix would be to make the nmr accept a range of version.
On Mon, Jun 15, 2009 at 18:14, ffrenchm<ff...@gmail.com> wrote:
>
> Hello,
>
> I followed the jbi cluster example successfully. Now my aim is to install a
> JBI consumer in node smx1 and a JBI provider in node smx2. As NMR and JBI
> bundle are not installed in the created smx instances I try to install them
> thanks the following commands :
>
> smx@root:/> admin/connect smx1
> Connecting to: localhost:8102
> Connected
> smx@smx1:/> features/addUrl
> mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.0.0/xml/features
> smx@smx1:/> features/install jbi
> ERROR CommandLineExecutionFailed:
> org.apache.geronimo.gshell.command.CommandException:
> org.osgi.framework.BundleException: Unresolved constraint in bundle 47:
> package; (&(package=org.springframework.osgi.context)(version>=1.2.0.rc1))
> smx@smx1:/> features/install nmr
> ERROR CommandLineExecutionFailed:
> org.apache.geronimo.gshell.command.CommandException:
> org.osgi.framework.BundleException: Unresolved constraint in bundle 51:
> package; (&(package=org.springframework.osgi.context)(version>=1.2.0.rc1))
>
> it's seems to me strange because it seems my spring-osgi dependencies are ok
> comparing to the parent smx instance :
>
> smx@root:/> osgi/list | grep spring
> [ 13] [Active ] [ ] [ 30] spring-osgi-io (1.2.0.m2)
> [ 30] [Active ] [ ] [ 30] spring-osgi-extender (1.2.0.m2)
> [ 38] [Active ] [ ] [ 30] spring-osgi-core (1.2.0.m2)
> [ 55] [Active ] [ ] [ 60] xbean-spring (3.5)
> [ 67] [Active ] [ ] [ 60] camel-spring (1.6.0)
> smx@root:/> admin/connect smx1
> Connecting to: localhost:8102
> Connected
> smx@smx1:/> osgi/list | grep spring
> [ 13] [Active ] [ ] [ 30] spring-osgi-io (1.2.0.m2)
> [ 30] [Active ] [ ] [ 30] spring-osgi-extender (1.2.0.m2)
> [ 38] [Active ] [ ] [ 30] spring-osgi-core (1.2.0.m2)
>
> Any ideas ?
>
> Thanks for all...
>
>
>
> gnodet wrote:
>>
>> On Fri, Jun 12, 2009 at 17:57, ffrenchm<ff...@gmail.com> wrote:
>>>
>>>
>>> gnodet wrote:
>>>>
>>>> No, there's no example, but it would be a good addition to the
>>>> distribution.
>>>> Maybe enhancing the existing example that demonstrates clustering
>>>> would be a good idea.
>>>>
>>> I would be happy to provide some JBI components samples which can work
>>> with
>>> the SMX4 cluster engine. But I'm blocking on some points.
>>>
>>> In one hand in your NMR component consumer example you have to create a
>>> proxy endpoint which you must register to the cluster engine and then you
>>> must send your exchange to this proxy endpoint. In the other hand in a
>>> full
>>> JBI component consumer you don't need to create any endpoint and you send
>>> your exchange directly to the desired target endpoint.
>>>
>>> To solve this point a solution I'm thinking on is to modify the treatment
>>> in
>>> the exchange listener of the cluster engine. AFAIK, currently the cluster
>>> engine exchange listener modify the exchange target to the cluster engine
>>> endpoint when the sender endpoint of this exchange is registered in the
>>> cluster engine. Do you don't think that it will make more sense to change
>>> the exchange target depending on the target endpoint of this exchange
>>> (depending for exemple if it's a clustered endpoint or transacted
>>> endpoint)
>>> ? With this solution nmr component could send directly the exchange to
>>> the
>>> desired target endpoint and without creating any proxy endpoint.
>>
>> Check out the following example:
>>
>> https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/examples/cluster/
>>
>> There's no need for a proxy. This is done this way in the unit tests
>> only because
>> the NMR client can't really be registered as clustered endpoint. It
>> works without
>> any need for the proxy for all JBI endpoints.
>>
>>> I know that you're waiting for the osgi remotes services specification
>>> and
>>> that my solution will certainly not work with the current non existing
>>> remote endpoint management in SMX4 but this solution will work in the
>>> case
>>> where two LOCAL endpoint want to use the cluster engine transactional
>>> functionality... It implies that as you can defined clustered endpoint
>>> you
>>> should also be able to define transacted endpoint. What do you think
>>> about
>>> this ?
>>
>> I guess it depends on the use case. Maybe both would be valuable.
>> Actually, a more generic solution would allow an exchange based filter to
>> be
>> set up and this would allow filtering on the source, target or any other
>> custom
>> filter. I'd have to check the code, but I don't think it would cause
>> any problem
>> for the cluster engine.
>>
>>>
>>> gnodet wrote:
>>>>
>>>> So you mean one queue per jms requestor pool, right ? I don't think it
>>>> would really solve the
>>>> potential problem with selectors though, but I agree this would enable
>>>> supporting multiple
>>>> transaction models at the same time.
>>>>
>>>
>>> I'm agree that it will not solve definitively any selectors problem but I
>>> think this strategy will help to enlarge the Servicemix 4 loading
>>> capacity
>>> and reduce some problems at the limits. For example :
>>>
>>> what to do when the clustering queue has a big big big depth (which can
>>> be a
>>> serious potentiality) and that it's blocking clustered JBI exchange ?
>>>
>>> what to do if there is to much consumer on the same queue ?
>>>
>>> (...)
>>>
>>>
>>> gnodet wrote:
>>>>
>>>> Currently, it can not be configured per endpoint, though it can be
>>>> done at the JMS connection level.
>>>> I don't see any problems moving this configuration bit down to the
>>>> cluster registration and have
>>>> a global flag for the default on the cluster engine. Makes sense ?
>>>>
>>>
>>> Well my original idea was to permit to set persistence parameter at the
>>> JBI
>>> exchange level because from my point of view it should be the JBI
>>> consumer
>>> components which have to decide if their exchange are persistent or not.
>>> I
>>> think it's important to keep the persistent granularity at the exchange
>>> level - this granularity could be also improved at the JMS message level
>>> but
>>> we'll see that point later if you're interested :)...
>>> --
>>> View this message in context:
>>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p24001682.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p24037734.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: How to turn off DONE messages
Posted by ffrenchm <ff...@gmail.com>.
Hello,
I followed the jbi cluster example successfully. Now my aim is to install a
JBI consumer in node smx1 and a JBI provider in node smx2. As NMR and JBI
bundle are not installed in the created smx instances I try to install them
thanks the following commands :
smx@root:/> admin/connect smx1
Connecting to: localhost:8102
Connected
smx@smx1:/> features/addUrl
mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.0.0/xml/features
smx@smx1:/> features/install jbi
ERROR CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
org.osgi.framework.BundleException: Unresolved constraint in bundle 47:
package; (&(package=org.springframework.osgi.context)(version>=1.2.0.rc1))
smx@smx1:/> features/install nmr
ERROR CommandLineExecutionFailed:
org.apache.geronimo.gshell.command.CommandException:
org.osgi.framework.BundleException: Unresolved constraint in bundle 51:
package; (&(package=org.springframework.osgi.context)(version>=1.2.0.rc1))
it's seems to me strange because it seems my spring-osgi dependencies are ok
comparing to the parent smx instance :
smx@root:/> osgi/list | grep spring
[ 13] [Active ] [ ] [ 30] spring-osgi-io (1.2.0.m2)
[ 30] [Active ] [ ] [ 30] spring-osgi-extender (1.2.0.m2)
[ 38] [Active ] [ ] [ 30] spring-osgi-core (1.2.0.m2)
[ 55] [Active ] [ ] [ 60] xbean-spring (3.5)
[ 67] [Active ] [ ] [ 60] camel-spring (1.6.0)
smx@root:/> admin/connect smx1
Connecting to: localhost:8102
Connected
smx@smx1:/> osgi/list | grep spring
[ 13] [Active ] [ ] [ 30] spring-osgi-io (1.2.0.m2)
[ 30] [Active ] [ ] [ 30] spring-osgi-extender (1.2.0.m2)
[ 38] [Active ] [ ] [ 30] spring-osgi-core (1.2.0.m2)
Any ideas ?
Thanks for all...
gnodet wrote:
>
> On Fri, Jun 12, 2009 at 17:57, ffrenchm<ff...@gmail.com> wrote:
>>
>>
>> gnodet wrote:
>>>
>>> No, there's no example, but it would be a good addition to the
>>> distribution.
>>> Maybe enhancing the existing example that demonstrates clustering
>>> would be a good idea.
>>>
>> I would be happy to provide some JBI components samples which can work
>> with
>> the SMX4 cluster engine. But I'm blocking on some points.
>>
>> In one hand in your NMR component consumer example you have to create a
>> proxy endpoint which you must register to the cluster engine and then you
>> must send your exchange to this proxy endpoint. In the other hand in a
>> full
>> JBI component consumer you don't need to create any endpoint and you send
>> your exchange directly to the desired target endpoint.
>>
>> To solve this point a solution I'm thinking on is to modify the treatment
>> in
>> the exchange listener of the cluster engine. AFAIK, currently the cluster
>> engine exchange listener modify the exchange target to the cluster engine
>> endpoint when the sender endpoint of this exchange is registered in the
>> cluster engine. Do you don't think that it will make more sense to change
>> the exchange target depending on the target endpoint of this exchange
>> (depending for exemple if it's a clustered endpoint or transacted
>> endpoint)
>> ? With this solution nmr component could send directly the exchange to
>> the
>> desired target endpoint and without creating any proxy endpoint.
>
> Check out the following example:
>
> https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/examples/cluster/
>
> There's no need for a proxy. This is done this way in the unit tests
> only because
> the NMR client can't really be registered as clustered endpoint. It
> works without
> any need for the proxy for all JBI endpoints.
>
>> I know that you're waiting for the osgi remotes services specification
>> and
>> that my solution will certainly not work with the current non existing
>> remote endpoint management in SMX4 but this solution will work in the
>> case
>> where two LOCAL endpoint want to use the cluster engine transactional
>> functionality... It implies that as you can defined clustered endpoint
>> you
>> should also be able to define transacted endpoint. What do you think
>> about
>> this ?
>
> I guess it depends on the use case. Maybe both would be valuable.
> Actually, a more generic solution would allow an exchange based filter to
> be
> set up and this would allow filtering on the source, target or any other
> custom
> filter. I'd have to check the code, but I don't think it would cause
> any problem
> for the cluster engine.
>
>>
>> gnodet wrote:
>>>
>>> So you mean one queue per jms requestor pool, right ? I don't think it
>>> would really solve the
>>> potential problem with selectors though, but I agree this would enable
>>> supporting multiple
>>> transaction models at the same time.
>>>
>>
>> I'm agree that it will not solve definitively any selectors problem but I
>> think this strategy will help to enlarge the Servicemix 4 loading
>> capacity
>> and reduce some problems at the limits. For example :
>>
>> what to do when the clustering queue has a big big big depth (which can
>> be a
>> serious potentiality) and that it's blocking clustered JBI exchange ?
>>
>> what to do if there is to much consumer on the same queue ?
>>
>> (...)
>>
>>
>> gnodet wrote:
>>>
>>> Currently, it can not be configured per endpoint, though it can be
>>> done at the JMS connection level.
>>> I don't see any problems moving this configuration bit down to the
>>> cluster registration and have
>>> a global flag for the default on the cluster engine. Makes sense ?
>>>
>>
>> Well my original idea was to permit to set persistence parameter at the
>> JBI
>> exchange level because from my point of view it should be the JBI
>> consumer
>> components which have to decide if their exchange are persistent or not.
>> I
>> think it's important to keep the persistent granularity at the exchange
>> level - this granularity could be also improved at the JMS message level
>> but
>> we'll see that point later if you're interested :)...
>> --
>> View this message in context:
>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p24001682.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p24037734.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: How to turn off DONE messages
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jun 12, 2009 at 17:57, ffrenchm<ff...@gmail.com> wrote:
>
>
> gnodet wrote:
>>
>> No, there's no example, but it would be a good addition to the
>> distribution.
>> Maybe enhancing the existing example that demonstrates clustering
>> would be a good idea.
>>
> I would be happy to provide some JBI components samples which can work with
> the SMX4 cluster engine. But I'm blocking on some points.
>
> In one hand in your NMR component consumer example you have to create a
> proxy endpoint which you must register to the cluster engine and then you
> must send your exchange to this proxy endpoint. In the other hand in a full
> JBI component consumer you don't need to create any endpoint and you send
> your exchange directly to the desired target endpoint.
>
> To solve this point a solution I'm thinking on is to modify the treatment in
> the exchange listener of the cluster engine. AFAIK, currently the cluster
> engine exchange listener modify the exchange target to the cluster engine
> endpoint when the sender endpoint of this exchange is registered in the
> cluster engine. Do you don't think that it will make more sense to change
> the exchange target depending on the target endpoint of this exchange
> (depending for exemple if it's a clustered endpoint or transacted endpoint)
> ? With this solution nmr component could send directly the exchange to the
> desired target endpoint and without creating any proxy endpoint.
Check out the following example:
https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/examples/cluster/
There's no need for a proxy. This is done this way in the unit tests
only because
the NMR client can't really be registered as clustered endpoint. It
works without
any need for the proxy for all JBI endpoints.
> I know that you're waiting for the osgi remotes services specification and
> that my solution will certainly not work with the current non existing
> remote endpoint management in SMX4 but this solution will work in the case
> where two LOCAL endpoint want to use the cluster engine transactional
> functionality... It implies that as you can defined clustered endpoint you
> should also be able to define transacted endpoint. What do you think about
> this ?
I guess it depends on the use case. Maybe both would be valuable.
Actually, a more generic solution would allow an exchange based filter to be
set up and this would allow filtering on the source, target or any other custom
filter. I'd have to check the code, but I don't think it would cause
any problem
for the cluster engine.
>
> gnodet wrote:
>>
>> So you mean one queue per jms requestor pool, right ? I don't think it
>> would really solve the
>> potential problem with selectors though, but I agree this would enable
>> supporting multiple
>> transaction models at the same time.
>>
>
> I'm agree that it will not solve definitively any selectors problem but I
> think this strategy will help to enlarge the Servicemix 4 loading capacity
> and reduce some problems at the limits. For example :
>
> what to do when the clustering queue has a big big big depth (which can be a
> serious potentiality) and that it's blocking clustered JBI exchange ?
>
> what to do if there is to much consumer on the same queue ?
>
> (...)
>
>
> gnodet wrote:
>>
>> Currently, it can not be configured per endpoint, though it can be
>> done at the JMS connection level.
>> I don't see any problems moving this configuration bit down to the
>> cluster registration and have
>> a global flag for the default on the cluster engine. Makes sense ?
>>
>
> Well my original idea was to permit to set persistence parameter at the JBI
> exchange level because from my point of view it should be the JBI consumer
> components which have to decide if their exchange are persistent or not. I
> think it's important to keep the persistent granularity at the exchange
> level - this granularity could be also improved at the JMS message level but
> we'll see that point later if you're interested :)...
> --
> View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p24001682.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: How to turn off DONE messages
Posted by ffrenchm <ff...@gmail.com>.
gnodet wrote:
>
> No, there's no example, but it would be a good addition to the
> distribution.
> Maybe enhancing the existing example that demonstrates clustering
> would be a good idea.
>
I would be happy to provide some JBI components samples which can work with
the SMX4 cluster engine. But I'm blocking on some points.
In one hand in your NMR component consumer example you have to create a
proxy endpoint which you must register to the cluster engine and then you
must send your exchange to this proxy endpoint. In the other hand in a full
JBI component consumer you don't need to create any endpoint and you send
your exchange directly to the desired target endpoint.
To solve this point a solution I'm thinking on is to modify the treatment in
the exchange listener of the cluster engine. AFAIK, currently the cluster
engine exchange listener modify the exchange target to the cluster engine
endpoint when the sender endpoint of this exchange is registered in the
cluster engine. Do you don't think that it will make more sense to change
the exchange target depending on the target endpoint of this exchange
(depending for exemple if it's a clustered endpoint or transacted endpoint)
? With this solution nmr component could send directly the exchange to the
desired target endpoint and without creating any proxy endpoint.
I know that you're waiting for the osgi remotes services specification and
that my solution will certainly not work with the current non existing
remote endpoint management in SMX4 but this solution will work in the case
where two LOCAL endpoint want to use the cluster engine transactional
functionality... It implies that as you can defined clustered endpoint you
should also be able to define transacted endpoint. What do you think about
this ?
gnodet wrote:
>
> So you mean one queue per jms requestor pool, right ? I don't think it
> would really solve the
> potential problem with selectors though, but I agree this would enable
> supporting multiple
> transaction models at the same time.
>
I'm agree that it will not solve definitively any selectors problem but I
think this strategy will help to enlarge the Servicemix 4 loading capacity
and reduce some problems at the limits. For example :
what to do when the clustering queue has a big big big depth (which can be a
serious potentiality) and that it's blocking clustered JBI exchange ?
what to do if there is to much consumer on the same queue ?
(...)
gnodet wrote:
>
> Currently, it can not be configured per endpoint, though it can be
> done at the JMS connection level.
> I don't see any problems moving this configuration bit down to the
> cluster registration and have
> a global flag for the default on the cluster engine. Makes sense ?
>
Well my original idea was to permit to set persistence parameter at the JBI
exchange level because from my point of view it should be the JBI consumer
components which have to decide if their exchange are persistent or not. I
think it's important to keep the persistent granularity at the exchange
level - this granularity could be also improved at the JMS message level but
we'll see that point later if you're interested :)...
--
View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p24001682.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: How to turn off DONE messages
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jun 12, 2009 at 15:37, ffrenchm<ff...@gmail.com> wrote:
>
> Hello,
>
> it's a very interesting discussion and after using the SMX4 cluster engine I
> would add some comments about its current implementation.
>
> First I based my work on the cluster engine JUnit tests. As you already know
> this JUnit tests could be seen as NMR component and no JBI component. I
> would like to know if you have any JBI component samples which are using the
> cluster engine for transactional purpose ?
No, there's no example, but it would be a good addition to the distribution.
Maybe enhancing the existing example that demonstrates clustering
would be a good idea.
> In the SMX4 cluster engine, one things I like is that the requestor pool can
> manage many transactional model. From my point of view it's a great progress
> comparing with SMX3 because the transactional model in an exchange flow
> shouldn't be imposed by the SMX container but by the JBI applications.
> Anyway one problem I have is that AFAIK the cluster engine manage only one
> jms requestor pool which manage only one transaction model. To be able to
> manage more than one transaction model in the same SMX container I've to
> create several cluster engine in my container (but maybe is there other
> solutions ?).
The only way is to define multiple cluster engines, because a single
cluster engine
can not support two different transaction models at the same time.
Having multiple cluster engine may lead to a few problems with the
current implementation
but I think they could be easily overcome. The first one I see is
that a cluster registration
for an endpoint has no way to tell which cluster engine it has to use.
I see two solutions to that:
* either add the required transactional model on the registration,
each engine actually processing
only the registration it can handle
* specify the cluster engine id a given registration should use
Not sure which one is better atm. The first one is more hidden for
the user, so it may be better.
> About queues management I appreciate the effort which has been done to be
> stingy with queuer resources but from my point of view you're SMX solutions
> on this problem is going from managing to much queues (one per endpoint) to
> managing to less queues (one per cluster). Finally I've the impression that
> the SMX4 cluster engine scalability could be improved if you give the
> availability for the cluster engine to manage a pool of jms requestor pool -
> which could be also a solution to my first problem. In my mind the policy to
> add new requestor pool (and so new JMS queue) will depend on the
> infrastructure administration and then SMX will be able to feat many other
> use cases we doesn't have in mind during development. What do you think
> about this ?
So you mean one queue per jms requestor pool, right ? I don't think it
would really solve the
potential problem with selectors though, but I agree this would enable
supporting multiple
transaction models at the same time.
> Finally I would like to know if you plan to manage exchange persistence
> parameter in the SMX4 cluster engine as it was the case in the SMX3 JCA flow
> ?
Currently, it can not be configured per endpoint, though it can be
done at the JMS connection level.
I don't see any problems moving this configuration bit down to the
cluster registration and have
a global flag for the default on the cluster engine. Makes sense ?
> Thanks for all
>
>
>
>
> gnodet wrote:
>>
>> On Sun, Jun 7, 2009 at 16:09, rotgier<ro...@gmail.com> wrote:
>>>
>>> Dear Guillaume,
>>>
>>> thanks for clarification. This sounds like a quite good solution for not
>>> sending DONEs !!
>>>
>>> Actually right now i am trying to understand the architecture of new SMX4
>>> clustering engine. I analyzed its code and I must admit that I am
>>> concerned
>>> about few implementation choices.
>>>
>>> In order to reduce the number of queues the clustering engine uses only
>>> one
>>> queue and then perform demultiplexing by leveraging JMS selectors (in
>>> SMX3
>>> it was a separete queue for each endpoint, which is discouraged by Adrian
>>> in
>>> his blog). I seems quite elegant solution but:
>>>
>>> 1. ActiveMQ is saying, that in case of Network of Brokers, the selectors
>>> may
>>> lead to some not optimal (or flawed) message distribution:
>>> "Imagine a situation when you have a producing broker forwarding messages
>>> to
>>> two receiving brokers and each of these two brokers have a consumer with
>>> different selector. Since no selectors are evaluated on the producer
>>> broker
>>> side, you can end up with all messages going to only one of the brokers,
>>> so
>>> messages with certain property will not be consumed."
>>> (http://activemq.apache.org/networks-of-brokers.html)
>>> Are you sure that in case of some more advanced Network of Brokers
>>> topology,
>>> the load-balancing (between the same selectors) and optimal message
>>> dispatch
>>> (avoiding unnecessary dispatch to brokers which selectors do not apply to
>>> messages being sent) work properly?
>>>
>>>
>>> 2. You do not maintain the list of endpoints exposed by other SMX
>>> containres
>>> (I believe that in SMX3 there was some JMS topic - it was used by every
>>> container to publish its endpoints). Therefore when, when an endpoint is
>>> being clustered (by OsgiSimpleClusterRegistration) its outgoing ME is
>>> translated to JMS and send-out, but there is no assurance that there will
>>> be
>>> actual JBI provider on the other side - simply the broker (or network of
>>> brokers) will not find any selector that would apply.
>>>
>>> 3. When creating selector You are choosing all endpoint registered in
>>> particular SMX container. However It could be useful if the user could
>>> specify which endpoints should be available in cluster and which should
>>> not
>>> (probably some simillar mechanism to OsgiSimpleClusterRegistration, but
>>> for
>>> the the recieving side would be sufficient).
>>
>> Right, the current design assumes that any local endpoint on a given
>> container is able to process a request from a remote endpoint.
>>
>>>
>>>
>>> Wouldn't it be better to apply a slight different architecture:
>>>
>>>
>>> I. Each container publishes the list of endpoints, which the user wants
>>> to
>>> expose to cluster. Therefore every container is aware where route ME of
>>> particular target (SERVICE_NAME, ENDPOINT_NAME etc.) and can instantly
>>> notify about non-existing target.
>>
>> Yes, that's one part that has been slightly left apart. The OSGi
>> Enterprise Expert Group is working on a specification called "Remote
>> Services" which we may want to leverage for the discovery of remote
>> endpoints. Still not sure if it completely fits our needs though.
>> Also, there's another need I'd like to integrate into this: the fact
>> that an endpoint can be put offline for a small time. Let's say you
>> are upgrading the endpoint implementation on one container, you don't
>> really want to end up with tons of exchanges in error because the
>> target endpoint suddenly became unavailable for a small period. I
>> guess there are two ways here:
>> * either inform the container that the endpoint will come up again
>> later (or that the endpoint will never come up again)
>> * maybe use a timeout to wait for one eligible target to be available
>>
>>> II. Each container creates a separe QUEUE for consuming messages directed
>>> to
>>> endpoints exposed in the cluster. On QUEUE, Container performs
>>> demultiplexing of incoming messages and delivers them to proper JBI
>>> endpoints (it could be similar to current demultiplexation, but the
>>> selectors would not be probably needed).
>>
>> Not sure if it would really work. There are multiple problems to solve.
>> One of the idea was to let the JMS broker to choose the exact target
>> endpoint so that the load balancing behavior of the JMS broker is as
>> effective as possible. In addition, the JBI targetting system can use
>> either service + endpoint, service or interface to target the
>> endpoint.
>> If we use one QUEUE per JBI container, this means we have to choose
>> the target endpoint very early in the process (before sending the JMS
>> message). The drawback is that if this container goes down, the
>> endpoint can not be reached anymore.
>> In ServiceMix 3, the design was to use one queue for each possible
>> endpoint, one queue for each possible service and one queue for each
>> possible interface. Each JBI container was listening onto queues for
>> which it was able to process messages.
>> One of the other goal was to not be too tied to ActiveMQ features, so that
>>
>>> III. rollbackOnErrors semantics can be applied in the same manner
>>
>> Yeah, I think this one is really important to keep if possible.
>>
>>> Such approach removes the disadvantage of using multiple queues (SMX3) in
>>> the same manner as current clustering approach, but also provides more
>>> cleaner behavior in case of more avanced topology of network of brokers.
>>>
>>>
>>> There is a possibility that I misunderstood some concepts of current
>>> Clustering Engine implementation. If so, then some further clarification
>>> would be nice :).
>>>
>>> I am interested in providing help in the further implementation of
>>> clustering engine in SMX4.
>>
>> Great! I'm really glad to start discussing this and see how we can
>> improve the current design.
>>
>>> Kind Regards,
>>>
>>> Marek Psiuk
>>>
>>>
>>>
>>>
>>> gnodet wrote:
>>>>
>>>> Well, it's not really turning OFF done messages. Those are mandatory
>>>> from a spec pov but also from an implementation pov, else you could
>>>> end up with lots of threads waiting forever (this is a common mistake
>>>> for new users dealing with the JBI api).
>>>>
>>>> If you use the Smx4 cluster engine, the default behavior is configured
>>>> so that the DONE messages will not end up being sent as JMS messages.
>>>> Actually, the behavior is controlled by the
>>>> <code>rollbackOnErrors</code> flag. If this flag is set and the
>>>> transaction model is not <code>None</code>, any exchange that comes
>>>> back in an <code>Error</code> status will lead to the transaction
>>>> being rolled back (or the ack not sent). This also means that no
>>>> error status can be conveyed back to the original exchange.
>>>>
>>>> So it's a bit more tricky then simply saying you don't need the DONE
>>>> message, because either the consumer expects a response or it does
>>>> not. So for an InOnly mep, either the client will wait for a response
>>>> which will be either a DONE or ERROR message, or it does not, and if
>>>> there is an error, the transaction (if any) will be rolled back by the
>>>> cluster engine on the provider side.
>>>>
>>>> 2009/6/1 rotgier <ro...@gmail.com>:
>>>>>
>>>>> Hmm,
>>>>>
>>>>> then what does Adrian Trenaman ment saying here:
>>>>> http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
>>>>> that "you can now optimize the JBI messaging layer to omit the use of
>>>>> JBI
>>>>> DONE messages: so, if you're implementing a one-way interaction over
>>>>> the
>>>>> JMS
>>>>> flow, you don't end up having to deal with an DONE that you simply
>>>>> don't
>>>>> need" ?
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Marek Psiuk
>>>>>
>>>>>
>>>>> Freeman Fang wrote:
>>>>>>
>>>>>> Hi,
>>>>>> No, I don't think so.
>>>>>> As MEP (message exchage pattern) defined in JBI spec all ends with
>>>>>> DONE
>>>>>> message, it's required by the JBI spec.
>>>>>> Freeman
>>>>>>
>>>>>>
>>>>>> rotgier wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> is there a possibility in SMX4 to turn off sending DONE messages? If
>>>>>>> so,
>>>>>>> then how to do it?
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>>
>>>>>>> Marek Psiuk
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Freeman Fang
>>>>>> ------------------------
>>>>>> Open Source SOA: http://fusesource.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23911414.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23998986.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: How to turn off DONE messages
Posted by ffrenchm <ff...@gmail.com>.
Hello,
it's a very interesting discussion and after using the SMX4 cluster engine I
would add some comments about its current implementation.
First I based my work on the cluster engine JUnit tests. As you already know
this JUnit tests could be seen as NMR component and no JBI component. I
would like to know if you have any JBI component samples which are using the
cluster engine for transactional purpose ?
In the SMX4 cluster engine, one things I like is that the requestor pool can
manage many transactional model. From my point of view it's a great progress
comparing with SMX3 because the transactional model in an exchange flow
shouldn't be imposed by the SMX container but by the JBI applications.
Anyway one problem I have is that AFAIK the cluster engine manage only one
jms requestor pool which manage only one transaction model. To be able to
manage more than one transaction model in the same SMX container I've to
create several cluster engine in my container (but maybe is there other
solutions ?).
About queues management I appreciate the effort which has been done to be
stingy with queuer resources but from my point of view you're SMX solutions
on this problem is going from managing to much queues (one per endpoint) to
managing to less queues (one per cluster). Finally I've the impression that
the SMX4 cluster engine scalability could be improved if you give the
availability for the cluster engine to manage a pool of jms requestor pool -
which could be also a solution to my first problem. In my mind the policy to
add new requestor pool (and so new JMS queue) will depend on the
infrastructure administration and then SMX will be able to feat many other
use cases we doesn't have in mind during development. What do you think
about this ?
Finally I would like to know if you plan to manage exchange persistence
parameter in the SMX4 cluster engine as it was the case in the SMX3 JCA flow
?
Thanks for all
gnodet wrote:
>
> On Sun, Jun 7, 2009 at 16:09, rotgier<ro...@gmail.com> wrote:
>>
>> Dear Guillaume,
>>
>> thanks for clarification. This sounds like a quite good solution for not
>> sending DONEs !!
>>
>> Actually right now i am trying to understand the architecture of new SMX4
>> clustering engine. I analyzed its code and I must admit that I am
>> concerned
>> about few implementation choices.
>>
>> In order to reduce the number of queues the clustering engine uses only
>> one
>> queue and then perform demultiplexing by leveraging JMS selectors (in
>> SMX3
>> it was a separete queue for each endpoint, which is discouraged by Adrian
>> in
>> his blog). I seems quite elegant solution but:
>>
>> 1. ActiveMQ is saying, that in case of Network of Brokers, the selectors
>> may
>> lead to some not optimal (or flawed) message distribution:
>> "Imagine a situation when you have a producing broker forwarding messages
>> to
>> two receiving brokers and each of these two brokers have a consumer with
>> different selector. Since no selectors are evaluated on the producer
>> broker
>> side, you can end up with all messages going to only one of the brokers,
>> so
>> messages with certain property will not be consumed."
>> (http://activemq.apache.org/networks-of-brokers.html)
>> Are you sure that in case of some more advanced Network of Brokers
>> topology,
>> the load-balancing (between the same selectors) and optimal message
>> dispatch
>> (avoiding unnecessary dispatch to brokers which selectors do not apply to
>> messages being sent) work properly?
>>
>>
>> 2. You do not maintain the list of endpoints exposed by other SMX
>> containres
>> (I believe that in SMX3 there was some JMS topic - it was used by every
>> container to publish its endpoints). Therefore when, when an endpoint is
>> being clustered (by OsgiSimpleClusterRegistration) its outgoing ME is
>> translated to JMS and send-out, but there is no assurance that there will
>> be
>> actual JBI provider on the other side - simply the broker (or network of
>> brokers) will not find any selector that would apply.
>>
>> 3. When creating selector You are choosing all endpoint registered in
>> particular SMX container. However It could be useful if the user could
>> specify which endpoints should be available in cluster and which should
>> not
>> (probably some simillar mechanism to OsgiSimpleClusterRegistration, but
>> for
>> the the recieving side would be sufficient).
>
> Right, the current design assumes that any local endpoint on a given
> container is able to process a request from a remote endpoint.
>
>>
>>
>> Wouldn't it be better to apply a slight different architecture:
>>
>>
>> I. Each container publishes the list of endpoints, which the user wants
>> to
>> expose to cluster. Therefore every container is aware where route ME of
>> particular target (SERVICE_NAME, ENDPOINT_NAME etc.) and can instantly
>> notify about non-existing target.
>
> Yes, that's one part that has been slightly left apart. The OSGi
> Enterprise Expert Group is working on a specification called "Remote
> Services" which we may want to leverage for the discovery of remote
> endpoints. Still not sure if it completely fits our needs though.
> Also, there's another need I'd like to integrate into this: the fact
> that an endpoint can be put offline for a small time. Let's say you
> are upgrading the endpoint implementation on one container, you don't
> really want to end up with tons of exchanges in error because the
> target endpoint suddenly became unavailable for a small period. I
> guess there are two ways here:
> * either inform the container that the endpoint will come up again
> later (or that the endpoint will never come up again)
> * maybe use a timeout to wait for one eligible target to be available
>
>> II. Each container creates a separe QUEUE for consuming messages directed
>> to
>> endpoints exposed in the cluster. On QUEUE, Container performs
>> demultiplexing of incoming messages and delivers them to proper JBI
>> endpoints (it could be similar to current demultiplexation, but the
>> selectors would not be probably needed).
>
> Not sure if it would really work. There are multiple problems to solve.
> One of the idea was to let the JMS broker to choose the exact target
> endpoint so that the load balancing behavior of the JMS broker is as
> effective as possible. In addition, the JBI targetting system can use
> either service + endpoint, service or interface to target the
> endpoint.
> If we use one QUEUE per JBI container, this means we have to choose
> the target endpoint very early in the process (before sending the JMS
> message). The drawback is that if this container goes down, the
> endpoint can not be reached anymore.
> In ServiceMix 3, the design was to use one queue for each possible
> endpoint, one queue for each possible service and one queue for each
> possible interface. Each JBI container was listening onto queues for
> which it was able to process messages.
> One of the other goal was to not be too tied to ActiveMQ features, so that
>
>> III. rollbackOnErrors semantics can be applied in the same manner
>
> Yeah, I think this one is really important to keep if possible.
>
>> Such approach removes the disadvantage of using multiple queues (SMX3) in
>> the same manner as current clustering approach, but also provides more
>> cleaner behavior in case of more avanced topology of network of brokers.
>>
>>
>> There is a possibility that I misunderstood some concepts of current
>> Clustering Engine implementation. If so, then some further clarification
>> would be nice :).
>>
>> I am interested in providing help in the further implementation of
>> clustering engine in SMX4.
>
> Great! I'm really glad to start discussing this and see how we can
> improve the current design.
>
>> Kind Regards,
>>
>> Marek Psiuk
>>
>>
>>
>>
>> gnodet wrote:
>>>
>>> Well, it's not really turning OFF done messages. Those are mandatory
>>> from a spec pov but also from an implementation pov, else you could
>>> end up with lots of threads waiting forever (this is a common mistake
>>> for new users dealing with the JBI api).
>>>
>>> If you use the Smx4 cluster engine, the default behavior is configured
>>> so that the DONE messages will not end up being sent as JMS messages.
>>> Actually, the behavior is controlled by the
>>> <code>rollbackOnErrors</code> flag. If this flag is set and the
>>> transaction model is not <code>None</code>, any exchange that comes
>>> back in an <code>Error</code> status will lead to the transaction
>>> being rolled back (or the ack not sent). This also means that no
>>> error status can be conveyed back to the original exchange.
>>>
>>> So it's a bit more tricky then simply saying you don't need the DONE
>>> message, because either the consumer expects a response or it does
>>> not. So for an InOnly mep, either the client will wait for a response
>>> which will be either a DONE or ERROR message, or it does not, and if
>>> there is an error, the transaction (if any) will be rolled back by the
>>> cluster engine on the provider side.
>>>
>>> 2009/6/1 rotgier <ro...@gmail.com>:
>>>>
>>>> Hmm,
>>>>
>>>> then what does Adrian Trenaman ment saying here:
>>>> http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
>>>> that "you can now optimize the JBI messaging layer to omit the use of
>>>> JBI
>>>> DONE messages: so, if you're implementing a one-way interaction over
>>>> the
>>>> JMS
>>>> flow, you don't end up having to deal with an DONE that you simply
>>>> don't
>>>> need" ?
>>>>
>>>> Kind Regards,
>>>>
>>>> Marek Psiuk
>>>>
>>>>
>>>> Freeman Fang wrote:
>>>>>
>>>>> Hi,
>>>>> No, I don't think so.
>>>>> As MEP (message exchage pattern) defined in JBI spec all ends with
>>>>> DONE
>>>>> message, it's required by the JBI spec.
>>>>> Freeman
>>>>>
>>>>>
>>>>> rotgier wrote:
>>>>>> Hello,
>>>>>>
>>>>>> is there a possibility in SMX4 to turn off sending DONE messages? If
>>>>>> so,
>>>>>> then how to do it?
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>> Marek Psiuk
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Freeman Fang
>>>>> ------------------------
>>>>> Open Source SOA: http://fusesource.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23911414.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23998986.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: How to turn off DONE messages
Posted by Guillaume Nodet <gn...@gmail.com>.
On Sun, Jun 7, 2009 at 16:09, rotgier<ro...@gmail.com> wrote:
>
> Dear Guillaume,
>
> thanks for clarification. This sounds like a quite good solution for not
> sending DONEs !!
>
> Actually right now i am trying to understand the architecture of new SMX4
> clustering engine. I analyzed its code and I must admit that I am concerned
> about few implementation choices.
>
> In order to reduce the number of queues the clustering engine uses only one
> queue and then perform demultiplexing by leveraging JMS selectors (in SMX3
> it was a separete queue for each endpoint, which is discouraged by Adrian in
> his blog). I seems quite elegant solution but:
>
> 1. ActiveMQ is saying, that in case of Network of Brokers, the selectors may
> lead to some not optimal (or flawed) message distribution:
> "Imagine a situation when you have a producing broker forwarding messages to
> two receiving brokers and each of these two brokers have a consumer with
> different selector. Since no selectors are evaluated on the producer broker
> side, you can end up with all messages going to only one of the brokers, so
> messages with certain property will not be consumed."
> (http://activemq.apache.org/networks-of-brokers.html)
> Are you sure that in case of some more advanced Network of Brokers topology,
> the load-balancing (between the same selectors) and optimal message dispatch
> (avoiding unnecessary dispatch to brokers which selectors do not apply to
> messages being sent) work properly?
>
>
> 2. You do not maintain the list of endpoints exposed by other SMX containres
> (I believe that in SMX3 there was some JMS topic - it was used by every
> container to publish its endpoints). Therefore when, when an endpoint is
> being clustered (by OsgiSimpleClusterRegistration) its outgoing ME is
> translated to JMS and send-out, but there is no assurance that there will be
> actual JBI provider on the other side - simply the broker (or network of
> brokers) will not find any selector that would apply.
>
> 3. When creating selector You are choosing all endpoint registered in
> particular SMX container. However It could be useful if the user could
> specify which endpoints should be available in cluster and which should not
> (probably some simillar mechanism to OsgiSimpleClusterRegistration, but for
> the the recieving side would be sufficient).
Right, the current design assumes that any local endpoint on a given
container is able to process a request from a remote endpoint.
>
>
> Wouldn't it be better to apply a slight different architecture:
>
>
> I. Each container publishes the list of endpoints, which the user wants to
> expose to cluster. Therefore every container is aware where route ME of
> particular target (SERVICE_NAME, ENDPOINT_NAME etc.) and can instantly
> notify about non-existing target.
Yes, that's one part that has been slightly left apart. The OSGi
Enterprise Expert Group is working on a specification called "Remote
Services" which we may want to leverage for the discovery of remote
endpoints. Still not sure if it completely fits our needs though.
Also, there's another need I'd like to integrate into this: the fact
that an endpoint can be put offline for a small time. Let's say you
are upgrading the endpoint implementation on one container, you don't
really want to end up with tons of exchanges in error because the
target endpoint suddenly became unavailable for a small period. I
guess there are two ways here:
* either inform the container that the endpoint will come up again
later (or that the endpoint will never come up again)
* maybe use a timeout to wait for one eligible target to be available
> II. Each container creates a separe QUEUE for consuming messages directed to
> endpoints exposed in the cluster. On QUEUE, Container performs
> demultiplexing of incoming messages and delivers them to proper JBI
> endpoints (it could be similar to current demultiplexation, but the
> selectors would not be probably needed).
Not sure if it would really work. There are multiple problems to solve.
One of the idea was to let the JMS broker to choose the exact target
endpoint so that the load balancing behavior of the JMS broker is as
effective as possible. In addition, the JBI targetting system can use
either service + endpoint, service or interface to target the
endpoint.
If we use one QUEUE per JBI container, this means we have to choose
the target endpoint very early in the process (before sending the JMS
message). The drawback is that if this container goes down, the
endpoint can not be reached anymore.
In ServiceMix 3, the design was to use one queue for each possible
endpoint, one queue for each possible service and one queue for each
possible interface. Each JBI container was listening onto queues for
which it was able to process messages.
One of the other goal was to not be too tied to ActiveMQ features, so that
> III. rollbackOnErrors semantics can be applied in the same manner
Yeah, I think this one is really important to keep if possible.
> Such approach removes the disadvantage of using multiple queues (SMX3) in
> the same manner as current clustering approach, but also provides more
> cleaner behavior in case of more avanced topology of network of brokers.
>
>
> There is a possibility that I misunderstood some concepts of current
> Clustering Engine implementation. If so, then some further clarification
> would be nice :).
>
> I am interested in providing help in the further implementation of
> clustering engine in SMX4.
Great! I'm really glad to start discussing this and see how we can
improve the current design.
> Kind Regards,
>
> Marek Psiuk
>
>
>
>
> gnodet wrote:
>>
>> Well, it's not really turning OFF done messages. Those are mandatory
>> from a spec pov but also from an implementation pov, else you could
>> end up with lots of threads waiting forever (this is a common mistake
>> for new users dealing with the JBI api).
>>
>> If you use the Smx4 cluster engine, the default behavior is configured
>> so that the DONE messages will not end up being sent as JMS messages.
>> Actually, the behavior is controlled by the
>> <code>rollbackOnErrors</code> flag. If this flag is set and the
>> transaction model is not <code>None</code>, any exchange that comes
>> back in an <code>Error</code> status will lead to the transaction
>> being rolled back (or the ack not sent). This also means that no
>> error status can be conveyed back to the original exchange.
>>
>> So it's a bit more tricky then simply saying you don't need the DONE
>> message, because either the consumer expects a response or it does
>> not. So for an InOnly mep, either the client will wait for a response
>> which will be either a DONE or ERROR message, or it does not, and if
>> there is an error, the transaction (if any) will be rolled back by the
>> cluster engine on the provider side.
>>
>> 2009/6/1 rotgier <ro...@gmail.com>:
>>>
>>> Hmm,
>>>
>>> then what does Adrian Trenaman ment saying here:
>>> http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
>>> that "you can now optimize the JBI messaging layer to omit the use of JBI
>>> DONE messages: so, if you're implementing a one-way interaction over the
>>> JMS
>>> flow, you don't end up having to deal with an DONE that you simply don't
>>> need" ?
>>>
>>> Kind Regards,
>>>
>>> Marek Psiuk
>>>
>>>
>>> Freeman Fang wrote:
>>>>
>>>> Hi,
>>>> No, I don't think so.
>>>> As MEP (message exchage pattern) defined in JBI spec all ends with DONE
>>>> message, it's required by the JBI spec.
>>>> Freeman
>>>>
>>>>
>>>> rotgier wrote:
>>>>> Hello,
>>>>>
>>>>> is there a possibility in SMX4 to turn off sending DONE messages? If
>>>>> so,
>>>>> then how to do it?
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Marek Psiuk
>>>>>
>>>>
>>>>
>>>> --
>>>> Freeman Fang
>>>> ------------------------
>>>> Open Source SOA: http://fusesource.com
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23911414.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: How to turn off DONE messages
Posted by rotgier <ro...@gmail.com>.
Dear Guillaume,
thanks for clarification. This sounds like a quite good solution for not
sending DONEs !!
Actually right now i am trying to understand the architecture of new SMX4
clustering engine. I analyzed its code and I must admit that I am concerned
about few implementation choices.
In order to reduce the number of queues the clustering engine uses only one
queue and then perform demultiplexing by leveraging JMS selectors (in SMX3
it was a separete queue for each endpoint, which is discouraged by Adrian in
his blog). I seems quite elegant solution but:
1. ActiveMQ is saying, that in case of Network of Brokers, the selectors may
lead to some not optimal (or flawed) message distribution:
"Imagine a situation when you have a producing broker forwarding messages to
two receiving brokers and each of these two brokers have a consumer with
different selector. Since no selectors are evaluated on the producer broker
side, you can end up with all messages going to only one of the brokers, so
messages with certain property will not be consumed."
(http://activemq.apache.org/networks-of-brokers.html)
Are you sure that in case of some more advanced Network of Brokers topology,
the load-balancing (between the same selectors) and optimal message dispatch
(avoiding unnecessary dispatch to brokers which selectors do not apply to
messages being sent) work properly?
2. You do not maintain the list of endpoints exposed by other SMX containres
(I believe that in SMX3 there was some JMS topic - it was used by every
container to publish its endpoints). Therefore when, when an endpoint is
being clustered (by OsgiSimpleClusterRegistration) its outgoing ME is
translated to JMS and send-out, but there is no assurance that there will be
actual JBI provider on the other side - simply the broker (or network of
brokers) will not find any selector that would apply.
3. When creating selector You are choosing all endpoint registered in
particular SMX container. However It could be useful if the user could
specify which endpoints should be available in cluster and which should not
(probably some simillar mechanism to OsgiSimpleClusterRegistration, but for
the the recieving side would be sufficient).
Wouldn't it be better to apply a slight different architecture:
I. Each container publishes the list of endpoints, which the user wants to
expose to cluster. Therefore every container is aware where route ME of
particular target (SERVICE_NAME, ENDPOINT_NAME etc.) and can instantly
notify about non-existing target.
II. Each container creates a separe QUEUE for consuming messages directed to
endpoints exposed in the cluster. On QUEUE, Container performs
demultiplexing of incoming messages and delivers them to proper JBI
endpoints (it could be similar to current demultiplexation, but the
selectors would not be probably needed).
III. rollbackOnErrors semantics can be applied in the same manner
Such approach removes the disadvantage of using multiple queues (SMX3) in
the same manner as current clustering approach, but also provides more
cleaner behavior in case of more avanced topology of network of brokers.
There is a possibility that I misunderstood some concepts of current
Clustering Engine implementation. If so, then some further clarification
would be nice :).
I am interested in providing help in the further implementation of
clustering engine in SMX4.
Kind Regards,
Marek Psiuk
gnodet wrote:
>
> Well, it's not really turning OFF done messages. Those are mandatory
> from a spec pov but also from an implementation pov, else you could
> end up with lots of threads waiting forever (this is a common mistake
> for new users dealing with the JBI api).
>
> If you use the Smx4 cluster engine, the default behavior is configured
> so that the DONE messages will not end up being sent as JMS messages.
> Actually, the behavior is controlled by the
> <code>rollbackOnErrors</code> flag. If this flag is set and the
> transaction model is not <code>None</code>, any exchange that comes
> back in an <code>Error</code> status will lead to the transaction
> being rolled back (or the ack not sent). This also means that no
> error status can be conveyed back to the original exchange.
>
> So it's a bit more tricky then simply saying you don't need the DONE
> message, because either the consumer expects a response or it does
> not. So for an InOnly mep, either the client will wait for a response
> which will be either a DONE or ERROR message, or it does not, and if
> there is an error, the transaction (if any) will be rolled back by the
> cluster engine on the provider side.
>
> 2009/6/1 rotgier <ro...@gmail.com>:
>>
>> Hmm,
>>
>> then what does Adrian Trenaman ment saying here:
>> http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
>> that "you can now optimize the JBI messaging layer to omit the use of JBI
>> DONE messages: so, if you're implementing a one-way interaction over the
>> JMS
>> flow, you don't end up having to deal with an DONE that you simply don't
>> need" ?
>>
>> Kind Regards,
>>
>> Marek Psiuk
>>
>>
>> Freeman Fang wrote:
>>>
>>> Hi,
>>> No, I don't think so.
>>> As MEP (message exchage pattern) defined in JBI spec all ends with DONE
>>> message, it's required by the JBI spec.
>>> Freeman
>>>
>>>
>>> rotgier wrote:
>>>> Hello,
>>>>
>>>> is there a possibility in SMX4 to turn off sending DONE messages? If
>>>> so,
>>>> then how to do it?
>>>>
>>>> Kind Regards,
>>>>
>>>> Marek Psiuk
>>>>
>>>
>>>
>>> --
>>> Freeman Fang
>>> ------------------------
>>> Open Source SOA: http://fusesource.com
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23911414.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: How to turn off DONE messages
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, it's not really turning OFF done messages. Those are mandatory
from a spec pov but also from an implementation pov, else you could
end up with lots of threads waiting forever (this is a common mistake
for new users dealing with the JBI api).
If you use the Smx4 cluster engine, the default behavior is configured
so that the DONE messages will not end up being sent as JMS messages.
Actually, the behavior is controlled by the
<code>rollbackOnErrors</code> flag. If this flag is set and the
transaction model is not <code>None</code>, any exchange that comes
back in an <code>Error</code> status will lead to the transaction
being rolled back (or the ack not sent). This also means that no
error status can be conveyed back to the original exchange.
So it's a bit more tricky then simply saying you don't need the DONE
message, because either the consumer expects a response or it does
not. So for an InOnly mep, either the client will wait for a response
which will be either a DONE or ERROR message, or it does not, and if
there is an error, the transaction (if any) will be rolled back by the
cluster engine on the provider side.
2009/6/1 rotgier <ro...@gmail.com>:
>
> Hmm,
>
> then what does Adrian Trenaman ment saying here:
> http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
> that "you can now optimize the JBI messaging layer to omit the use of JBI
> DONE messages: so, if you're implementing a one-way interaction over the JMS
> flow, you don't end up having to deal with an DONE that you simply don't
> need" ?
>
> Kind Regards,
>
> Marek Psiuk
>
>
> Freeman Fang wrote:
>>
>> Hi,
>> No, I don't think so.
>> As MEP (message exchage pattern) defined in JBI spec all ends with DONE
>> message, it's required by the JBI spec.
>> Freeman
>>
>>
>> rotgier wrote:
>>> Hello,
>>>
>>> is there a possibility in SMX4 to turn off sending DONE messages? If so,
>>> then how to do it?
>>>
>>> Kind Regards,
>>>
>>> Marek Psiuk
>>>
>>
>>
>> --
>> Freeman Fang
>> ------------------------
>> Open Source SOA: http://fusesource.com
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: How to turn off DONE messages
Posted by rotgier <ro...@gmail.com>.
Hmm,
then what does Adrian Trenaman ment saying here:
http://trenaman.blogspot.com/2009/03/new-jms-flow-in-servicemix-4.html
that "you can now optimize the JBI messaging layer to omit the use of JBI
DONE messages: so, if you're implementing a one-way interaction over the JMS
flow, you don't end up having to deal with an DONE that you simply don't
need" ?
Kind Regards,
Marek Psiuk
Freeman Fang wrote:
>
> Hi,
> No, I don't think so.
> As MEP (message exchage pattern) defined in JBI spec all ends with DONE
> message, it's required by the JBI spec.
> Freeman
>
>
> rotgier wrote:
>> Hello,
>>
>> is there a possibility in SMX4 to turn off sending DONE messages? If so,
>> then how to do it?
>>
>> Kind Regards,
>>
>> Marek Psiuk
>>
>
>
> --
> Freeman Fang
> ------------------------
> Open Source SOA: http://fusesource.com
>
>
>
--
View this message in context: http://www.nabble.com/How-to-turn-off-DONE-messages-tp23810732p23810931.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: How to turn off DONE messages
Posted by Adrian Trenaman <tr...@progress.com>.
Hi Freeman,
As far as I know, Guillaume put in some smarts that allow you to
configure-out the DONE messages if you like for SMX4.
@Guillaume: your thoughts?
/Ade
Freeman Fang wrote:
> Hi,
> No, I don't think so.
> As MEP (message exchage pattern) defined in JBI spec all ends with
> DONE message, it's required by the JBI spec.
> Freeman
>
>
> rotgier wrote:
>> Hello,
>>
>> is there a possibility in SMX4 to turn off sending DONE messages? If so,
>> then how to do it?
>>
>> Kind Regards,
>>
>> Marek Psiuk
>>
>
>
Re: How to turn off DONE messages
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
No, I don't think so.
As MEP (message exchage pattern) defined in JBI spec all ends with DONE
message, it's required by the JBI spec.
Freeman
rotgier wrote:
> Hello,
>
> is there a possibility in SMX4 to turn off sending DONE messages? If so,
> then how to do it?
>
> Kind Regards,
>
> Marek Psiuk
>
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com