You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Harald Wellmann <hw...@gmail.com> on 2013/02/09 16:05:49 UTC
SJMS and InOut
I'm rather confused by the different flavours of InOut.
What's the difference between
1) from("direct:calculatorProxy")
.inOut("sjms:calculator-queue");
and
2) from("direct:calculatorProxy")
.to("sjms:calculator-queue?exchangePattern=InOut");
inOut() in 1) does not seem to make any difference from to() at all.
Best regards,
Harald
Re: SJMS and InOut
Posted by Harald Wellmann <hw...@gmail.com>.
Ok, I've created an issue with a failing test attached:
https://issues.apache.org/jira/browse/CAMEL-6065
Best regards,
Harald
2013/2/11 Claus Ibsen <cl...@gmail.com>:
> On Sun, Feb 10, 2013 at 10:38 AM, Harald Wellmann
> <hw...@gmail.com> wrote:
>> Yes, I read the Javadoc. I have a test case which deterministically breaks
>> when replacing 2) by 1).
>>
>> Given that SJMS is not yet released, should I create a JIRA issue, or post
>> the details somewhere else?
>>
>
> Yeah if you can create an unit test for the camel-sjms that shows the
> issue, then that would be good.
> Then we can add that test as part of a fix.
>
> Feel free to log a JIRA and attach the unit test / patch
> http://camel.apache.org/support
>
>
>> Best regards,
>> Harald
>>
>>
>> Am 10.02.2013 06:51, schrieb Claus Ibsen:
>>
>>> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com>
>>> wrote:
>>>>
>>>> I'm rather confused by the different flavours of InOut.
>>>>
>>>> What's the difference between
>>>>
>>>> 1) from("direct:calculatorProxy")
>>>> .inOut("sjms:calculator-queue");
>>>>
>>>> and
>>>>
>>>> 2) from("direct:calculatorProxy")
>>>> .to("sjms:calculator-queue?exchangePattern=InOut");
>>>>
>>>> inOut() in 1) does not seem to make any difference from to() at all.
>>>>
>>>
>>> Its the same.
>>>
>>> There is a couple of ways of doing this. See the request-reply eip
>>> pattern.
>>> http://camel.apache.org/request-reply.html
>>>
>>> And when using Java code, you can also read the javadoc of the methods
>>> as well as they may also contains some information.
>>>
>>>
>>>
>>>
>>>> Best regards,
>>>> Harald
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
Re: SJMS and InOut
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Feb 10, 2013 at 10:38 AM, Harald Wellmann
<hw...@gmail.com> wrote:
> Yes, I read the Javadoc. I have a test case which deterministically breaks
> when replacing 2) by 1).
>
> Given that SJMS is not yet released, should I create a JIRA issue, or post
> the details somewhere else?
>
Yeah if you can create an unit test for the camel-sjms that shows the
issue, then that would be good.
Then we can add that test as part of a fix.
Feel free to log a JIRA and attach the unit test / patch
http://camel.apache.org/support
> Best regards,
> Harald
>
>
> Am 10.02.2013 06:51, schrieb Claus Ibsen:
>
>> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com>
>> wrote:
>>>
>>> I'm rather confused by the different flavours of InOut.
>>>
>>> What's the difference between
>>>
>>> 1) from("direct:calculatorProxy")
>>> .inOut("sjms:calculator-queue");
>>>
>>> and
>>>
>>> 2) from("direct:calculatorProxy")
>>> .to("sjms:calculator-queue?exchangePattern=InOut");
>>>
>>> inOut() in 1) does not seem to make any difference from to() at all.
>>>
>>
>> Its the same.
>>
>> There is a couple of ways of doing this. See the request-reply eip
>> pattern.
>> http://camel.apache.org/request-reply.html
>>
>> And when using Java code, you can also read the javadoc of the methods
>> as well as they may also contains some information.
>>
>>
>>
>>
>>> Best regards,
>>> Harald
>>>
>>
>>
>>
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: SJMS and InOut
Posted by Harald Wellmann <hw...@gmail.com>.
Yes, I read the Javadoc. I have a test case which deterministically
breaks when replacing 2) by 1).
Given that SJMS is not yet released, should I create a JIRA issue, or
post the details somewhere else?
Best regards,
Harald
Am 10.02.2013 06:51, schrieb Claus Ibsen:
> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com> wrote:
>> I'm rather confused by the different flavours of InOut.
>>
>> What's the difference between
>>
>> 1) from("direct:calculatorProxy")
>> .inOut("sjms:calculator-queue");
>>
>> and
>>
>> 2) from("direct:calculatorProxy")
>> .to("sjms:calculator-queue?exchangePattern=InOut");
>>
>> inOut() in 1) does not seem to make any difference from to() at all.
>>
>
> Its the same.
>
> There is a couple of ways of doing this. See the request-reply eip pattern.
> http://camel.apache.org/request-reply.html
>
> And when using Java code, you can also read the javadoc of the methods
> as well as they may also contains some information.
>
>
>
>
>> Best regards,
>> Harald
>>
>
>
>
Re: SJMS and InOut
Posted by Harald Wellmann <hw...@gmail.com>.
Scott,
basically, its one-to-one. Camel (S)JMS + Proxies + Beans (Spring or
EJB) is our standard remoting mechanism.
A client system has an outgoing route starting with a Camel proxy for FooService
from("direct:fooProxy).to("sjms:queue:fooQueue")
and the server system has a corresponding incoming route
from("sjms:queue:fooQueue).to("ejb:FooServiceImpl").
There is one queue for each service. At the moment each service
happens to be either fully InOnly or InOut, but it is very likely for
a service to have mix of InOnly and InOut methods, and some of the
InOut methods might by synchronous (returning T) and others
asynchronous (returning Future<T>). So ideally, all these different
flavours of exchanges should be handled by the same SJMS endpoint, to
avoid splitting a service interface into several parts just because of
a restriction in the Camel infrastructure.
Hope that makes it clearer.
Best regards,
Harald
Re: SJMS and InOut
Posted by Scott England-Sullivan <su...@gmail.com>.
Harald,
First, thanks again for your feedback. I will update the documentation with a warning clarifying the limitation.
If you could clarify your use case for me, is this a one to many configuration? One endpoint definition to many routes?
Thanks again,
Scott ES
On Feb 13, 2013, at 12:59 AM, Harald Wellmann <hw...@gmail.com> wrote:
> Well, it should be clearly documented that inOut() does not have the
> desired effect and that camel-sjms behaves differently than camel-jms
> in this respect.
>
> I can live with the current approach, and I'm eager to see a release
> of camel-sjms in 2.11 to get rid of the transitive Spring dependency
> in my Java EE app which is not required except by camel-jms.
>
> But it would be useful to remove that restriction in the next release.
>
> We use bean invocations tunnelled through JMS a lot, and it should be
> possible to have InOut methods and InOnly methods in the same service
> interface, tunneled through the same queue.
>
> Best regards,
> Harald
Re: SJMS and InOut
Posted by Scott England-Sullivan <su...@gmail.com>.
Thanks for the clarification Claus. I will update the documentation and plan for an update in a later release.
Best Regards,
Scott ES
On Feb 13, 2013, at 12:59 AM, Harald Wellmann <hw...@gmail.com> wrote:
> Well, it should be clearly documented that inOut() does not have the
> desired effect and that camel-sjms behaves differently than camel-jms
> in this respect.
>
> I can live with the current approach, and I'm eager to see a release
> of camel-sjms in 2.11 to get rid of the transitive Spring dependency
> in my Java EE app which is not required except by camel-jms.
>
> But it would be useful to remove that restriction in the next release.
>
> We use bean invocations tunnelled through JMS a lot, and it should be
> possible to have InOut methods and InOnly methods in the same service
> interface, tunneled through the same queue.
>
> Best regards,
> Harald
Re: SJMS and InOut
Posted by Harald Wellmann <hw...@gmail.com>.
Well, it should be clearly documented that inOut() does not have the
desired effect and that camel-sjms behaves differently than camel-jms
in this respect.
I can live with the current approach, and I'm eager to see a release
of camel-sjms in 2.11 to get rid of the transitive Spring dependency
in my Java EE app which is not required except by camel-jms.
But it would be useful to remove that restriction in the next release.
We use bean invocations tunnelled through JMS a lot, and it should be
possible to have InOut methods and InOnly methods in the same service
interface, tunneled through the same queue.
Best regards,
Harald
Re: SJMS and InOut
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Feb 12, 2013 at 6:45 PM, Scott England-Sullivan
<su...@gmail.com> wrote:
> Sorry but I misunderstood that behavior.
>
> SJMS is designed to be agressive, meaning that the intent of the message
> flow is expected at initialization so the endpoint can be optimized with
> all necessary resources cached. In this case the producer has already been
> created and cached as an InOnly handler. Because of my misunderstanding
> there isn't a path for changing the MEP at runtime.
>
> I will take a look at a redesign to accomodate both initialization and
> runtime management of the endpoint. I am not sure that would be ready
> though for 2.11 given that it appears to be immanent.
>
> Any concerns?
>
Well its up to the component developers to decide what the component support.
In the case of camel-sjms, then its fine to require the
producer/consumer to be configured "up-front" if they are InOnly or
InOut.
This has the advantage as you can setup the resources up front in the
start|stop lifecycles etc.
So its fine for sjms to behave as it does now. We can add some notes
in the docs.
The behavior in camel-jms has just been from the very beginning of
Camel 1.0 that it supported doing in the producer, when an Exchange
was processed.
If we want camel-jms and camel-sjms to behavior similar, then we can
add that logic later in eg Camel 2.12/3.0 or what comes next.
But yes adding that kind of init logic at runtime is harder, and you
have to deal with concurrency etc.
>
> On Tue, Feb 12, 2013 at 12:14 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Mon, Feb 11, 2013 at 5:56 PM, Scott England-Sullivan
>> <su...@gmail.com> wrote:
>> > After looking at it they don't appear to behave the same. The parameter
>> sets the exchange pattern at initialization while the inOut() method sets
>> the exchange at runtime.
>> >
>> > Is that what you would expect Claus?
>> >
>>
>> Yes, there is a difference.
>> InOut will set the MEP to InOut and after the call, restore it back to
>> what it was before.
>>
>> But the SJMS producer should likely detect the MEP on the Exchange and
>> react accordingly.
>> This is what we do in camel-jms.
>>
>> There is ExchangeHelper.isOutCapable(exchange) we use to detect if we
>> want to do request/reply or one way.
>>
>>
>> > Scott England-Sullivan
>> > blog:sully6768.blogspot.com twitter:@sully6768
>> >
>> > On Feb 9, 2013, at 9:51 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> >
>> >> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com>
>> wrote:
>> >>> I'm rather confused by the different flavours of InOut.
>> >>>
>> >>> What's the difference between
>> >>>
>> >>> 1) from("direct:calculatorProxy")
>> >>> .inOut("sjms:calculator-queue");
>> >>>
>> >>> and
>> >>>
>> >>> 2) from("direct:calculatorProxy")
>> >>> .to("sjms:calculator-queue?exchangePattern=InOut");
>> >>>
>> >>> inOut() in 1) does not seem to make any difference from to() at all.
>> >>
>> >> Its the same.
>> >>
>> >> There is a couple of ways of doing this. See the request-reply eip
>> pattern.
>> >> http://camel.apache.org/request-reply.html
>> >>
>> >> And when using Java code, you can also read the javadoc of the methods
>> >> as well as they may also contains some information.
>> >>
>> >>
>> >>
>> >>
>> >>> Best regards,
>> >>> Harald
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> Red Hat, Inc.
>> >> FuseSource is now part of Red Hat
>> >> Email: cibsen@redhat.com
>> >> Web: http://fusesource.com
>> >> Twitter: davsclaus
>> >> Blog: http://davsclaus.com
>> >> Author of Camel in Action: http://www.manning.com/ibsen
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: cibsen@redhat.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
>
>
>
> --
> --
> Scott England-Sullivan
> Apache Camel Committer
> Principal Consultant / Sr. Architect | Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: fusesource.com <http://www.fusesource.com> |
> redhat.com<http://www.redhat.com>
> Blog: sully6768.blogspot.com
> Twitter: sully6768
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: SJMS and InOut
Posted by Scott England-Sullivan <su...@gmail.com>.
Sorry but I misunderstood that behavior.
SJMS is designed to be agressive, meaning that the intent of the message
flow is expected at initialization so the endpoint can be optimized with
all necessary resources cached. In this case the producer has already been
created and cached as an InOnly handler. Because of my misunderstanding
there isn't a path for changing the MEP at runtime.
I will take a look at a redesign to accomodate both initialization and
runtime management of the endpoint. I am not sure that would be ready
though for 2.11 given that it appears to be immanent.
Any concerns?
On Tue, Feb 12, 2013 at 12:14 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Feb 11, 2013 at 5:56 PM, Scott England-Sullivan
> <su...@gmail.com> wrote:
> > After looking at it they don't appear to behave the same. The parameter
> sets the exchange pattern at initialization while the inOut() method sets
> the exchange at runtime.
> >
> > Is that what you would expect Claus?
> >
>
> Yes, there is a difference.
> InOut will set the MEP to InOut and after the call, restore it back to
> what it was before.
>
> But the SJMS producer should likely detect the MEP on the Exchange and
> react accordingly.
> This is what we do in camel-jms.
>
> There is ExchangeHelper.isOutCapable(exchange) we use to detect if we
> want to do request/reply or one way.
>
>
> > Scott England-Sullivan
> > blog:sully6768.blogspot.com twitter:@sully6768
> >
> > On Feb 9, 2013, at 9:51 PM, Claus Ibsen <cl...@gmail.com> wrote:
> >
> >> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com>
> wrote:
> >>> I'm rather confused by the different flavours of InOut.
> >>>
> >>> What's the difference between
> >>>
> >>> 1) from("direct:calculatorProxy")
> >>> .inOut("sjms:calculator-queue");
> >>>
> >>> and
> >>>
> >>> 2) from("direct:calculatorProxy")
> >>> .to("sjms:calculator-queue?exchangePattern=InOut");
> >>>
> >>> inOut() in 1) does not seem to make any difference from to() at all.
> >>
> >> Its the same.
> >>
> >> There is a couple of ways of doing this. See the request-reply eip
> pattern.
> >> http://camel.apache.org/request-reply.html
> >>
> >> And when using Java code, you can also read the javadoc of the methods
> >> as well as they may also contains some information.
> >>
> >>
> >>
> >>
> >>> Best regards,
> >>> Harald
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> Red Hat, Inc.
> >> FuseSource is now part of Red Hat
> >> Email: cibsen@redhat.com
> >> Web: http://fusesource.com
> >> Twitter: davsclaus
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
--
Scott England-Sullivan
Apache Camel Committer
Principal Consultant / Sr. Architect | Red Hat, Inc.
FuseSource is now part of Red Hat
Web: fusesource.com <http://www.fusesource.com> |
redhat.com<http://www.redhat.com>
Blog: sully6768.blogspot.com
Twitter: sully6768
Re: SJMS and InOut
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Feb 11, 2013 at 5:56 PM, Scott England-Sullivan
<su...@gmail.com> wrote:
> After looking at it they don't appear to behave the same. The parameter sets the exchange pattern at initialization while the inOut() method sets the exchange at runtime.
>
> Is that what you would expect Claus?
>
Yes, there is a difference.
InOut will set the MEP to InOut and after the call, restore it back to
what it was before.
But the SJMS producer should likely detect the MEP on the Exchange and
react accordingly.
This is what we do in camel-jms.
There is ExchangeHelper.isOutCapable(exchange) we use to detect if we
want to do request/reply or one way.
> Scott England-Sullivan
> blog:sully6768.blogspot.com twitter:@sully6768
>
> On Feb 9, 2013, at 9:51 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com> wrote:
>>> I'm rather confused by the different flavours of InOut.
>>>
>>> What's the difference between
>>>
>>> 1) from("direct:calculatorProxy")
>>> .inOut("sjms:calculator-queue");
>>>
>>> and
>>>
>>> 2) from("direct:calculatorProxy")
>>> .to("sjms:calculator-queue?exchangePattern=InOut");
>>>
>>> inOut() in 1) does not seem to make any difference from to() at all.
>>
>> Its the same.
>>
>> There is a couple of ways of doing this. See the request-reply eip pattern.
>> http://camel.apache.org/request-reply.html
>>
>> And when using Java code, you can also read the javadoc of the methods
>> as well as they may also contains some information.
>>
>>
>>
>>
>>> Best regards,
>>> Harald
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: cibsen@redhat.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: SJMS and InOut
Posted by Scott England-Sullivan <su...@gmail.com>.
After looking at it they don't appear to behave the same. The parameter sets the exchange pattern at initialization while the inOut() method sets the exchange at runtime.
Is that what you would expect Claus?
Scott England-Sullivan
blog:sully6768.blogspot.com twitter:@sully6768
On Feb 9, 2013, at 9:51 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com> wrote:
>> I'm rather confused by the different flavours of InOut.
>>
>> What's the difference between
>>
>> 1) from("direct:calculatorProxy")
>> .inOut("sjms:calculator-queue");
>>
>> and
>>
>> 2) from("direct:calculatorProxy")
>> .to("sjms:calculator-queue?exchangePattern=InOut");
>>
>> inOut() in 1) does not seem to make any difference from to() at all.
>
> Its the same.
>
> There is a couple of ways of doing this. See the request-reply eip pattern.
> http://camel.apache.org/request-reply.html
>
> And when using Java code, you can also read the javadoc of the methods
> as well as they may also contains some information.
>
>
>
>
>> Best regards,
>> Harald
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
Re: SJMS and InOut
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hw...@gmail.com> wrote:
> I'm rather confused by the different flavours of InOut.
>
> What's the difference between
>
> 1) from("direct:calculatorProxy")
> .inOut("sjms:calculator-queue");
>
> and
>
> 2) from("direct:calculatorProxy")
> .to("sjms:calculator-queue?exchangePattern=InOut");
>
> inOut() in 1) does not seem to make any difference from to() at all.
>
Its the same.
There is a couple of ways of doing this. See the request-reply eip pattern.
http://camel.apache.org/request-reply.html
And when using Java code, you can also read the javadoc of the methods
as well as they may also contains some information.
> Best regards,
> Harald
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen