You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by "Andreas Schaefer (2)" <an...@madplanet.com> on 2007/10/17 00:13:48 UTC
Re: ServiceMix Bean issues with send()
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I had another look into the JBI specification and looking at the
Figure 9 I would say that when a Message Exchange (ME) is sent back
to the NMR it should go back to the Caller. Now what happens is that
when the Target Bean is sending the message back to the NMR through
the Delivery Channel the message is handled by the Consumer Endpoint
of the Target Bean because of using the Mirror ME. This means at the
end the ME is going back to the Target Bean.
This is what I see:
- - - Source Bean creates ME and sets the Provider as service and sends
it through the Delivery Channel
- - - Provider Endpoint of Target Bean is receiving the ME and hands it
over to its Bean
- Target Bean is handling the ME, sets the response and send the
message back through the Delivery Channel
- - - Delivery Channel is handing the ME to the service mentioned in
the Mirror of the given ME
- - - Consumer Endpoint of Target Bean is receiving the ME and hands it
over to its Bean
- Target Bean is handling the Response now which I think is WRONG
Is there something fundamentally wrong with the general ME handling
in the asynchronous case? Shouldn't the Mirror inside the ME point
back to the provider (the one that send the ME originally)? And if
shouldn't it be set by the Delivery Channel in the send of the provider?
Thanks - Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHFTecs4gPTNnP0gkRAhlaAJsEUdCmko0bcIXZoI5g/ua0nn1eOwCffMT9
ZmUe5nTrJ/xl75xz2oJYdts=
=vnwj
-----END PGP SIGNATURE-----
Re: ServiceMix Bean issues with send()
Posted by Guillaume Nodet <gn...@gmail.com>.
So, basically, there is no concept of consumer endpoint: an exchange
is sent from a component to an endpoint. Inside servicemix
components, we usually have this concept of consumer endpoint, but in
such case, this means that the component has to dispatch the incoming
exchange back to the endpoint that sent it.
On 10/19/07, Andreas Schaefer <an...@madplanet.com> wrote:
> HI Guillaume
>
> I hope you are right even though I am not quite sure how you want to
> figure out the service name of the consumer. I still think it is a
> problem of the core. Even if we can fix the problem inside the Bean BC
> the problem may arise on other BCs as well. I think that we should not
> only have a source component but also a source service name or any form
> of internal identification of the source SU.
>
> BTW today I am at home and so we may can discuss this through IRC if you
> want.
>
> -Andy
>
> Guillaume Nodet wrote:
> > I had some time to look at your test case on the plane and i think i
> > found a fix. In all cases i'm quite sure that the problem comes from
> > the component and not from the container. The fix is mainly to inject
> > on the pojo a delivery channel that will track consumer exchanges sent
> > by the bean. That way, the component will know about the exchange and
> > will not throw an exception.
> >
> > 2007/10/19, Andreas Schaefer (2) <an...@madplanet.com>:
> > Tomorrow I plan to try to fix this issue but if anyone sees a flaw in
> > my design please stop beforehand.
> >
> > Today I finally resolved the problem of how does ServiceMix know to
> > which component it should send the Message Exchange (ME) back even
> > though it uses the wrong Service Name. Inside the
> > AbstractFlow.doRouting() it uses the SourceId from the ME to find the
> > correct Binding Component (BC). That is why in my test project the
> > call goes back tot he Bean BC even though it tries to call a service
> > that is actually based on a Script BC. This makes me hopeful that
> > applying the same logic to the service name could fix the issue.
> >
> > That is what I want to do to fix it:
> >
> > - service name is removed from the packet and placed inside the ME
> > (maybe also the endpoint)
> > - the ME.setServiceName() is actually set on the MIRROR.serviceName
> > member (so that I don't have to change the logic of switching the ME
> > with its MIRROR)
> > - the consumer's service name is set on the ME before the ME is sent
> > onto the flow. This is either done on the Message Exchange Factory or
> > on the Delivery Channel which is probably the better choice because
> > then on the way back the service name of the provider can also be set
> > if not already done). I just have to figure out how to obtain the
> > service name of the sending SU from within the Delivery Channel.
> >
> > I think that should do the trick even though I don't know what the
> > implications on the SYNCHRONOUS ME are and hope that I am not going
> > to open Pandora's Box.
> >
> > Thanks - Andy
> >
> >>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix Bean issues with send()
Posted by Andreas Schaefer <an...@madplanet.com>.
HI Guillaume
I hope you are right even though I am not quite sure how you want to
figure out the service name of the consumer. I still think it is a
problem of the core. Even if we can fix the problem inside the Bean BC
the problem may arise on other BCs as well. I think that we should not
only have a source component but also a source service name or any form
of internal identification of the source SU.
BTW today I am at home and so we may can discuss this through IRC if you
want.
-Andy
Guillaume Nodet wrote:
> I had some time to look at your test case on the plane and i think i
> found a fix. In all cases i'm quite sure that the problem comes from
> the component and not from the container. The fix is mainly to inject
> on the pojo a delivery channel that will track consumer exchanges sent
> by the bean. That way, the component will know about the exchange and
> will not throw an exception.
>
> 2007/10/19, Andreas Schaefer (2) <an...@madplanet.com>:
> Tomorrow I plan to try to fix this issue but if anyone sees a flaw in
> my design please stop beforehand.
>
> Today I finally resolved the problem of how does ServiceMix know to
> which component it should send the Message Exchange (ME) back even
> though it uses the wrong Service Name. Inside the
> AbstractFlow.doRouting() it uses the SourceId from the ME to find the
> correct Binding Component (BC). That is why in my test project the
> call goes back tot he Bean BC even though it tries to call a service
> that is actually based on a Script BC. This makes me hopeful that
> applying the same logic to the service name could fix the issue.
>
> That is what I want to do to fix it:
>
> - service name is removed from the packet and placed inside the ME
> (maybe also the endpoint)
> - the ME.setServiceName() is actually set on the MIRROR.serviceName
> member (so that I don't have to change the logic of switching the ME
> with its MIRROR)
> - the consumer's service name is set on the ME before the ME is sent
> onto the flow. This is either done on the Message Exchange Factory or
> on the Delivery Channel which is probably the better choice because
> then on the way back the service name of the provider can also be set
> if not already done). I just have to figure out how to obtain the
> service name of the sending SU from within the Delivery Channel.
>
> I think that should do the trick even though I don't know what the
> implications on the SYNCHRONOUS ME are and hope that I am not going
> to open Pandora's Box.
>
> Thanks - Andy
>
>>
Re: ServiceMix Bean issues with send()
Posted by Guillaume Nodet <gn...@gmail.com>.
I had some time to look at your test case on the plane and i think i
found a fix. In all cases i'm quite sure that the problem comes from
the component and not from the container. The fix is mainly to inject
on the pojo a delivery channel that will track consumer exchanges sent
by the bean. That way, the component will know about the exchange and
will not throw an exception.
2007/10/19, Andreas Schaefer (2) <an...@madplanet.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tomorrow I plan to try to fix this issue but if anyone sees a flaw in
> my design please stop beforehand.
>
> Today I finally resolved the problem of how does ServiceMix know to
> which component it should send the Message Exchange (ME) back even
> though it uses the wrong Service Name. Inside the
> AbstractFlow.doRouting() it uses the SourceId from the ME to find the
> correct Binding Component (BC). That is why in my test project the
> call goes back tot he Bean BC even though it tries to call a service
> that is actually based on a Script BC. This makes me hopeful that
> applying the same logic to the service name could fix the issue.
>
> That is what I want to do to fix it:
>
> - - service name is removed from the packet and placed inside the ME
> (maybe also the endpoint)
> - - the ME.setServiceName() is actually set on the MIRROR.serviceName
> member (so that I don't have to change the logic of switching the ME
> with its MIRROR)
> - - the consumer's service name is set on the ME before the ME is sent
> onto the flow. This is either done on the Message Exchange Factory or
> on the Delivery Channel which is probably the better choice because
> then on the way back the service name of the provider can also be set
> if not already done). I just have to figure out how to obtain the
> service name of the sending SU from within the Delivery Channel.
>
> I think that should do the trick even though I don't know what the
> implications on the SYNCHRONOUS ME are and hope that I am not going
> to open Pandora's Box.
>
> Thanks - Andy
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHGADWs4gPTNnP0gkRAsNpAJ9knS8kX0NfIbAMW+uGgBjIN0i3zQCfceDi
> rdw1L46NBoZnzqQzLYILOEw=
> =VDq2
> -----END PGP SIGNATURE-----
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix Bean issues with send()
Posted by "Andreas Schaefer (2)" <an...@madplanet.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tomorrow I plan to try to fix this issue but if anyone sees a flaw in
my design please stop beforehand.
Today I finally resolved the problem of how does ServiceMix know to
which component it should send the Message Exchange (ME) back even
though it uses the wrong Service Name. Inside the
AbstractFlow.doRouting() it uses the SourceId from the ME to find the
correct Binding Component (BC). That is why in my test project the
call goes back tot he Bean BC even though it tries to call a service
that is actually based on a Script BC. This makes me hopeful that
applying the same logic to the service name could fix the issue.
That is what I want to do to fix it:
- - service name is removed from the packet and placed inside the ME
(maybe also the endpoint)
- - the ME.setServiceName() is actually set on the MIRROR.serviceName
member (so that I don't have to change the logic of switching the ME
with its MIRROR)
- - the consumer's service name is set on the ME before the ME is sent
onto the flow. This is either done on the Message Exchange Factory or
on the Delivery Channel which is probably the better choice because
then on the way back the service name of the provider can also be set
if not already done). I just have to figure out how to obtain the
service name of the sending SU from within the Delivery Channel.
I think that should do the trick even though I don't know what the
implications on the SYNCHRONOUS ME are and hope that I am not going
to open Pandora's Box.
Thanks - Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHGADWs4gPTNnP0gkRAsNpAJ9knS8kX0NfIbAMW+uGgBjIN0i3zQCfceDi
rdw1L46NBoZnzqQzLYILOEw=
=VDq2
-----END PGP SIGNATURE-----
Re: ServiceMix Bean issues with send()
Posted by "Andreas Schaefer (2)" <an...@madplanet.com>.
I tried to send a test project along with this email but the email
was rejected. So I created a JIRA issue: https://issues.apache.org/
activemq/browse/SM-1110 which contains the project ZIP file. This was
the original email:
I guess I lost everybody. Attached you will find a complete Maven 2
test project that hopefully illustrates the problem or shows what I
am doing wrong.
You should be able to run the project by just calling "mvn install".
It uses ServiceMix 3.1.2, the Bean and Script component. The crucial
part in the LOG output I see are these lines:
2007-10-18 10:32:07,851 [ed-0:1-thread-1] INFO
InOutReceiver - process(), send back response, ME:
InOut[
id: ID:10.250.1.197-115b42ceaed-2:0
status: Active
role: provider
service: {urn:xTest}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
2007-10-18 10:32:07,857 [ed-0:1-thread-1] DEBUG
DeliveryChannelImpl - Send ID:10.250.1.197-115b42ceaed-2:0
in DeliveryChannel{ID:10.250.1.197-115b42ceaed-0:1}
2007-10-18 10:32:07,858 [ed-0:1-thread-1] DEBUG
SedaFlow - Called Flow send
2007-10-18 10:32:07,859 [ed-0:1-thread-2] DEBUG
SedaQueue -
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@bc4e89 dequeued
exchange: InOut[
id: ID:10.250.1.197-115b42ceaed-2:0
status: Active
role: consumer
service: {urn:xTest}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
2007-10-18 10:32:07,859 [ed-0:1-thread-2] DEBUG
BeanComponent - Received exchange: status: Active,
role: consumer
2007-10-18 10:32:07,859 [ed-0:1-thread-2] DEBUG
BeanComponent - Retrieved correlation id: ID:
10.250.1.197-115b42ceaed-2:0
2007-10-18 10:32:07,862 [ed-0:1-thread-2] ERROR
BeanComponent - Error processing exchange InOut[
id: ID:10.250.1.197-115b42ceaed-2:0
status: Active
role: consumer
service: {urn:xTest}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
java.lang.IllegalStateException: Receiving unknown consumer exchange:
InOut[
id: ID:10.250.1.197-115b42ceaed-2:0
status: Active
role: consumer
service: {urn:xTest}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
at org.apache.servicemix.bean.BeanEndpoint.onConsumerExchange
(BeanEndpoint.java:266)
at org.apache.servicemix.bean.BeanEndpoint.process
(BeanEndpoint.java:196)
at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess
(AsyncBaseLifeCycle.java:489)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
(AsyncBaseLifeCycle.java:463)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange
(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound
(DeliveryChannelImpl.java:595)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting
(AbstractFlow.java:174)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting
(SedaFlow.java:176)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run
(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:613)
The InOutReceiver Script component is setting a response (Out
Message) and sending the message back through the delivery channel.
The message is then picked up correctly by a BeanEndpoint but because
of the wrong address (service) it ends up in the Consumer Endpoint of
the wrong Bean. The exception (Unkown consumer exchange) is another
problem that comes from the fact that the list of requests are a
private member of an Endpoint and the Consumer and the Provider are
two different Endpoint instances. I fixed that issue but it does not
make any difference.
Thanks - Andy
On Oct 17, 2007, at 3:42 PM, Andreas Schaefer (2) wrote:
> Hi Geeks
>
> I am moving this thread to the DEV mailing list because it not
> about using ServiceMix anymore. The problem is that when using the
> asynchronous message exchange that the response is not sent back to
> the calling SU but to the Provider Endpoint of the called SU.
>
> I just keep on spinning here. I have a closer look at the
> MessageExchangeImpl and saw that the Mirror references the same
> packet and beside the ROLE and STATUS everything else is set or
> retrieved from the packet. This means that always the MIRROR is
> pointing to the same service, endpoint etc.
>
> Creating a new ME it will be of role CONSUMER and the mirror is of
> role PROVIDER. The Delivery Channel (DC) will send the ME using the
> mirror and so the DC will send it to the target service PROVIDER
> endpoint. When the response is sent back the DC will use the MIRROR
> (of the MIRROR), which has not the role CONSUMER, but because of
> the same packet it will use the same Service / Endpoint / Interface
> Name meaning the message is sent back to the same service with the
> only exception that the ME is send to the CONSUMER endpoint instead.
>
> But shouldn't it be that the ME references the CONSUMER endpoint of
> the caller (the service that created and sent the message
> originally) and the MIRROR references the PROVIDER endpoint of the
> called service (the service that received the original message)
> which most likely are not the same SU.
>
> This would mean that the addressing parts (service name, endpoint,
> interface name) must be removed from the "packet" and kept separate
> from the ME and its MIRROR. We might also need to swap the ME and
> MIRROR so that the ME is pointing to the PROVIDER and the MIRROR
> pointing to the CONSUMER. This means that the DC will use the ME
> instead of the MIRROR to send the ME and NMR or the receiving DC
> must swap the ME / MIRROR so that the Provider Endpoint receives
> the MIRROR which is subsequently pointing back to the calling service.
>
> Let me know what you think?
>
> Thanks - Andy
>
> On Oct 17, 2007, at 9:11 AM, Andreas Schaefer (2) wrote:
>
>> Hi Guillaume
>>
>> I tried something new using the SCRIPT as the provider service
>> rather than another BEAN. Now I think I see a little bit more what
>> is going wrong. What is happening is that the response is handled
>> by the BeanComponent (which is good) but because it is using the
>> MIRROR member to which it sends the response to it fails because
>> of an unknown request (it should work because I fix that issue
>> locally).
>>
>> From my understanding I think the message is properly sent back to
>> the correct BC/SE, in this case the Bean Component, but because it
>> uses the MIRROR as the address it sends it to the wrong SU, which
>> in this case is the SCRIPT SU which is not even a BEAN. It seems
>> to me that the MIRROR is pointing to the consumer endpoint of the
>> provider SU rather than the consumer SU. That is my log output:
>>
>> [Notes Andy]: Here I send the InOut Message to he Provider:
>>
>> 2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
>> ScriptInOutControllerBean - onMessageExchange() send new ME:
>> InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> ]
>> 2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
>> BeanComponent - Created correlation id: ID:
>> 10.250.1.197-115aea91258-2:0
>> 2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
>> DeliveryChannelImpl - Send ID:
>> 10.250.1.197-115aea91258-2:0 in DeliveryChannel{ID:
>> 10.250.1.197-115aea91258-0:0}
>>
>> [Notes Andy]: "AS-LOG" are log statements I added to Smx
>>
>> 2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
>> DeliveryChannelImpl - AS-LOG, doSend(), ME: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> ]
>> 2007-10-17 08:51:53,516 [58-0:0-thread-1] INFO
>> DeliveryChannelImpl - AS-LOG, doSend(), send exchange
>> to MIRROR: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: provider
>> service: {urn:scout}script-receiver-service
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> ]
>> 2007-10-17 08:51:53,516 [58-0:0-thread-1] DEBUG
>> SedaFlow - Called Flow send
>> 2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
>> SedaQueue -
>> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@4507ed
>> dequeued exchange: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: provider
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> ]
>> 2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
>> ScriptComponent - Received exchange: status:
>> Active, role: provider
>> 2007-10-17 08:51:53,519 [58-0:1-thread-1] DEBUG
>> ScriptComponent - Retrieved correlation id: ID:
>> 10.250.1.197-115aea91258-2:0
>>
>> ...
>>
>> [Notes Andy]: Script acknowledgment of the message received which
>> also sends the message back with a response
>>
>> Hello, I got an input message <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>>
>> 2007-10-17 08:51:53,591 [58-0:1-thread-1] DEBUG
>> DeliveryChannelImpl - Send ID:
>> 10.250.1.197-115aea91258-2:0 in DeliveryChannel{ID:
>> 10.250.1.197-115aea91258-0:1}
>> 2007-10-17 08:51:53,594 [58-0:1-thread-1] INFO
>> DeliveryChannelImpl - AS-LOG, doSend(), ME: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: provider
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
>> ]
>>
>> [Notes Andy]: As you can see the MIRROR is pointing to the same
>> provider service just with the ROLE of CONSUMER but this Service
>> is a SCRIPT and not a BEAN
>>
>> 2007-10-17 08:51:53,596 [58-0:1-thread-1] INFO
>> DeliveryChannelImpl - AS-LOG, doSend(), send exchange
>> to MIRROR: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
>> ]
>> 2007-10-17 08:51:53,596 [58-0:1-thread-1] DEBUG
>> SedaFlow - Called Flow send
>> 2007-10-17 08:51:53,597 [58-0:1-thread-2] DEBUG
>> SedaQueue -
>> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@aeaea6
>> dequeued exchange: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
>> ]
>>
>> [Notes Andy]: Correctly the BEAN gets the Message but because of
>> the wrong Service name in the MIRROR it tries to call the Consumer
>> endpoint of the provider -> FAILURE
>>
>> 2007-10-17 08:51:53,597 [58-0:1-thread-2] DEBUG
>> BeanComponent - Received exchange: status:
>> Active, role: consumer
>> 2007-10-17 08:51:53,598 [58-0:1-thread-2] DEBUG
>> BeanComponent - Retrieved correlation id: ID:
>> 10.250.1.197-115aea91258-2:0
>> 2007-10-17 08:51:53,600 [58-0:1-thread-2] INFO
>> BeanComponent - onConsumerExchange(), cor-id: ID:
>> 10.250.1.197-115aea91258-2:0, ME: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
>> ]
>> 2007-10-17 08:51:53,600 [58-0:1-thread-2] INFO
>> BeanComponent - AS-LOG, findRequest(), corr-id:
>> ID:10.250.1.197-115aea91258-2:0, bean:
>> org.apache.servicemix.bean.BeanComponent@2f717c
>> 2007-10-17 08:51:53,602 [58-0:1-thread-2] ERROR
>> BeanComponent - Error processing exchange InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
>> ]
>> java.lang.IllegalStateException: Receiving unknown consumer
>> exchange: InOut[
>> id: ID:10.250.1.197-115aea91258-2:0
>> status: Active
>> role: consumer
>> service: {urn:scout}script-receiver-service
>> endpoint: in-out-receiver
>> operation: IdontCare: 0
>> in: <?xml version="1.0" encoding="UTF-8"?
>> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
>> ]
>> at
>> org.apache.servicemix.bean.BeanEndpoint.onConsumerExchange
>> (BeanEndpoint.java:274)
>>
>> The solution seems to be to set the MIRROR to the consumer rather
>> the provider as it is now. I would think that the
>> DeliveryChannelImpl should do that when the message is sent by the
>> consumer, right?
>>
>> Thanks - Andy
>>
>> On Oct 16, 2007, at 6:47 PM, Andreas Schaefer wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi Guillaume
>>>
>>> If I am not mistaken then there seems to be a problem either in
>>> the DeliveryChannelImpl or the NMR inside ServiceMix when
>>> handling asynchronous message exchanges. If you could help
>>> understand how ServiceMix discovers the consumer Endpoint it has
>>> to send a response back from the provider I could have a closer
>>> look into what is going wrong. According to your outline below I
>>> did everything correctly. If my hunch is correct then the problem
>>> is symptomatic in Smx and is not limited to the Bean component.
>>>
>>> Please see below:
>>>
>>> On Oct 16, 2007, at 6:29 PM, Guillaume Nodet wrote:
>>>
>>>> You should not care about the mirror stuff, which is internal to
>>>> ServiceMix. Briefly, each component only see one side of the
>>>> exchange
>>>> (while the other one see the mirror). So each time the exchange
>>>> goes
>>>> from the consumer to the provider, the mirror exchange is
>>>> delivered.
>>>> But components are not aware of that at all.
>>>
>>> I don't care about the MIRROR member but I see that this seems to
>>> be the issue that is causing the problem.
>>>
>>>> From a JBI point of view, there are mainly four different meps,
>>>> each
>>>> mep being handled in a different way. For an InOut mep, here
>>>> are the
>>>> steps:
>>>> * the consumer component create an exchange and send it
>>>> through the NMR
>>>
>>> done
>>>
>>>> * the NMR select the target endpoint using the metadata and
>>>> put it
>>>> in the endpoint's component DeliveryChannel
>>>> * the component picks the exchange from its DeliveryChannel,
>>>> process it by populating the out message, and send it through the
>>>> DeliveryChannel
>>>
>>> done
>>>
>>>> * the NMR route the exchange back to the consumer component
>>>> * the consumer component picks the exchange from its
>>>> DeliveryChannel, process the response, set the status to DONE
>>>> and sent
>>>> it back through the DC
>>>
>>> Here is where things fail with asynchronous message exchange (send
>>> ()) and the Smx Bean. The delivery channel or NMR is sending the
>>> ME back to the same Bean just the opposite endpoint (consumer
>>> endpoint). This is probably due to the MIRROR member (it is just
>>> my guess).
>>>
>>>> * the NMR route the exchange to the target component
>>>> * the target component picks the exchange from its DC and
>>>> usually
>>>> just discard it
>>>>
>>>> On 10/17/07, Andreas Schaefer (2)
>>>> <an...@madplanet.com> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> I had another look into the JBI specification and looking at the
>>>>> Figure 9 I would say that when a Message Exchange (ME) is sent
>>>>> back
>>>>> to the NMR it should go back to the Caller. Now what happens is
>>>>> that
>>>>> when the Target Bean is sending the message back to the NMR
>>>>> through
>>>>> the Delivery Channel the message is handled by the Consumer
>>>>> Endpoint
>>>>> of the Target Bean because of using the Mirror ME. This means
>>>>> at the
>>>>> end the ME is going back to the Target Bean.
>>>>>
>>>>> This is what I see:
>>>>>
>>>>> - - - Source Bean creates ME and sets the Provider as service
>>>>> and sends
>>>>> it through the Delivery Channel
>>>>>
>>>>> - - - Provider Endpoint of Target Bean is receiving the ME and
>>>>> hands it
>>>>> over to its Bean
>>>>> - Target Bean is handling the ME, sets the response and
>>>>> send the
>>>>> message back through the Delivery Channel
>>>>> - - - Delivery Channel is handing the ME to the service
>>>>> mentioned in
>>>>> the Mirror of the given ME
>>>>> - - - Consumer Endpoint of Target Bean is receiving the ME and
>>>>> hands it
>>>>> over to its Bean
>>>>> - Target Bean is handling the Response now which I think is
>>>>> WRONG
>>>>>
>>>>> Is there something fundamentally wrong with the general ME
>>>>> handling
>>>>> in the asynchronous case? Shouldn't the Mirror inside the ME point
>>>>> back to the provider (the one that send the ME originally)? And if
>>>>> shouldn't it be set by the Delivery Channel in the send of the
>>>>> provider?
>>>>>
>>>>> Thanks - Andy
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.7 (Darwin)
>>>>>
>>>>> iD8DBQFHFTecs4gPTNnP0gkRAhlaAJsEUdCmko0bcIXZoI5g/ua0nn1eOwCffMT9
>>>>> ZmUe5nTrJ/xl75xz2oJYdts=
>>>>> =vnwj
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (Darwin)
>>>
>>> iD8DBQFHFWnHs4gPTNnP0gkRAg8RAJ91wQWGvAtljtKUlihC2fGFIq2OhACfQkdA
>>> sNM1ANMul8OEBg0EyWqYwhk=
>>> =KVZH
>>> -----END PGP SIGNATURE-----
>>
>
Re: ServiceMix Bean issues with send()
Posted by "Andreas Schaefer (2)" <an...@madplanet.com>.
Hi Geeks
I am moving this thread to the DEV mailing list because it not about
using ServiceMix anymore. The problem is that when using the
asynchronous message exchange that the response is not sent back to
the calling SU but to the Provider Endpoint of the called SU.
I just keep on spinning here. I have a closer look at the
MessageExchangeImpl and saw that the Mirror references the same
packet and beside the ROLE and STATUS everything else is set or
retrieved from the packet. This means that always the MIRROR is
pointing to the same service, endpoint etc.
Creating a new ME it will be of role CONSUMER and the mirror is of
role PROVIDER. The Delivery Channel (DC) will send the ME using the
mirror and so the DC will send it to the target service PROVIDER
endpoint. When the response is sent back the DC will use the MIRROR
(of the MIRROR), which has not the role CONSUMER, but because of the
same packet it will use the same Service / Endpoint / Interface Name
meaning the message is sent back to the same service with the only
exception that the ME is send to the CONSUMER endpoint instead.
But shouldn't it be that the ME references the CONSUMER endpoint of
the caller (the service that created and sent the message originally)
and the MIRROR references the PROVIDER endpoint of the called service
(the service that received the original message) which most likely
are not the same SU.
This would mean that the addressing parts (service name, endpoint,
interface name) must be removed from the "packet" and kept separate
from the ME and its MIRROR. We might also need to swap the ME and
MIRROR so that the ME is pointing to the PROVIDER and the MIRROR
pointing to the CONSUMER. This means that the DC will use the ME
instead of the MIRROR to send the ME and NMR or the receiving DC must
swap the ME / MIRROR so that the Provider Endpoint receives the
MIRROR which is subsequently pointing back to the calling service.
Let me know what you think?
Thanks - Andy
On Oct 17, 2007, at 9:11 AM, Andreas Schaefer (2) wrote:
> Hi Guillaume
>
> I tried something new using the SCRIPT as the provider service
> rather than another BEAN. Now I think I see a little bit more what
> is going wrong. What is happening is that the response is handled
> by the BeanComponent (which is good) but because it is using the
> MIRROR member to which it sends the response to it fails because of
> an unknown request (it should work because I fix that issue locally).
>
> From my understanding I think the message is properly sent back to
> the correct BC/SE, in this case the Bean Component, but because it
> uses the MIRROR as the address it sends it to the wrong SU, which
> in this case is the SCRIPT SU which is not even a BEAN. It seems to
> me that the MIRROR is pointing to the consumer endpoint of the
> provider SU rather than the consumer SU. That is my log output:
>
> [Notes Andy]: Here I send the InOut Message to he Provider:
>
> 2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
> ScriptInOutControllerBean - onMessageExchange() send new ME:
> InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> ]
> 2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
> BeanComponent - Created correlation id: ID:
> 10.250.1.197-115aea91258-2:0
> 2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
> DeliveryChannelImpl - Send ID:
> 10.250.1.197-115aea91258-2:0 in DeliveryChannel{ID:
> 10.250.1.197-115aea91258-0:0}
>
> [Notes Andy]: "AS-LOG" are log statements I added to Smx
>
> 2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
> DeliveryChannelImpl - AS-LOG, doSend(), ME: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> ]
> 2007-10-17 08:51:53,516 [58-0:0-thread-1] INFO
> DeliveryChannelImpl - AS-LOG, doSend(), send exchange to
> MIRROR: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: provider
> service: {urn:scout}script-receiver-service
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> ]
> 2007-10-17 08:51:53,516 [58-0:0-thread-1] DEBUG
> SedaFlow - Called Flow send
> 2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
> SedaQueue -
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@4507ed dequeued
> exchange: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: provider
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> ]
> 2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
> ScriptComponent - Received exchange: status: Active,
> role: provider
> 2007-10-17 08:51:53,519 [58-0:1-thread-1] DEBUG
> ScriptComponent - Retrieved correlation id: ID:
> 10.250.1.197-115aea91258-2:0
>
> ...
>
> [Notes Andy]: Script acknowledgment of the message received which
> also sends the message back with a response
>
> Hello, I got an input message <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
>
> 2007-10-17 08:51:53,591 [58-0:1-thread-1] DEBUG
> DeliveryChannelImpl - Send ID:
> 10.250.1.197-115aea91258-2:0 in DeliveryChannel{ID:
> 10.250.1.197-115aea91258-0:1}
> 2007-10-17 08:51:53,594 [58-0:1-thread-1] INFO
> DeliveryChannelImpl - AS-LOG, doSend(), ME: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: provider
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
> ]
>
> [Notes Andy]: As you can see the MIRROR is pointing to the same
> provider service just with the ROLE of CONSUMER but this Service is
> a SCRIPT and not a BEAN
>
> 2007-10-17 08:51:53,596 [58-0:1-thread-1] INFO
> DeliveryChannelImpl - AS-LOG, doSend(), send exchange to
> MIRROR: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
> ]
> 2007-10-17 08:51:53,596 [58-0:1-thread-1] DEBUG
> SedaFlow - Called Flow send
> 2007-10-17 08:51:53,597 [58-0:1-thread-2] DEBUG
> SedaQueue -
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@aeaea6 dequeued
> exchange: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
> ]
>
> [Notes Andy]: Correctly the BEAN gets the Message but because of
> the wrong Service name in the MIRROR it tries to call the Consumer
> endpoint of the provider -> FAILURE
>
> 2007-10-17 08:51:53,597 [58-0:1-thread-2] DEBUG
> BeanComponent - Received exchange: status: Active,
> role: consumer
> 2007-10-17 08:51:53,598 [58-0:1-thread-2] DEBUG
> BeanComponent - Retrieved correlation id: ID:
> 10.250.1.197-115aea91258-2:0
> 2007-10-17 08:51:53,600 [58-0:1-thread-2] INFO
> BeanComponent - onConsumerExchange(), cor-id: ID:
> 10.250.1.197-115aea91258-2:0, ME: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
> ]
> 2007-10-17 08:51:53,600 [58-0:1-thread-2] INFO
> BeanComponent - AS-LOG, findRequest(), corr-id: ID:
> 10.250.1.197-115aea91258-2:0, bean:
> org.apache.servicemix.bean.BeanComponent@2f717c
> 2007-10-17 08:51:53,602 [58-0:1-thread-2] ERROR
> BeanComponent - Error processing exchange InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
> ]
> java.lang.IllegalStateException: Receiving unknown consumer
> exchange: InOut[
> id: ID:10.250.1.197-115aea91258-2:0
> status: Active
> role: consumer
> service: {urn:scout}script-receiver-service
> endpoint: in-out-receiver
> operation: IdontCare: 0
> in: <?xml version="1.0" encoding="UTF-8"?
> ><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
> ]
> at
> org.apache.servicemix.bean.BeanEndpoint.onConsumerExchange
> (BeanEndpoint.java:274)
>
> The solution seems to be to set the MIRROR to the consumer rather
> the provider as it is now. I would think that the
> DeliveryChannelImpl should do that when the message is sent by the
> consumer, right?
>
> Thanks - Andy
>
> On Oct 16, 2007, at 6:47 PM, Andreas Schaefer wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Guillaume
>>
>> If I am not mistaken then there seems to be a problem either in
>> the DeliveryChannelImpl or the NMR inside ServiceMix when handling
>> asynchronous message exchanges. If you could help understand how
>> ServiceMix discovers the consumer Endpoint it has to send a
>> response back from the provider I could have a closer look into
>> what is going wrong. According to your outline below I did
>> everything correctly. If my hunch is correct then the problem is
>> symptomatic in Smx and is not limited to the Bean component.
>>
>> Please see below:
>>
>> On Oct 16, 2007, at 6:29 PM, Guillaume Nodet wrote:
>>
>>> You should not care about the mirror stuff, which is internal to
>>> ServiceMix. Briefly, each component only see one side of the
>>> exchange
>>> (while the other one see the mirror). So each time the exchange
>>> goes
>>> from the consumer to the provider, the mirror exchange is delivered.
>>> But components are not aware of that at all.
>>
>> I don't care about the MIRROR member but I see that this seems to
>> be the issue that is causing the problem.
>>
>>> From a JBI point of view, there are mainly four different meps, each
>>> mep being handled in a different way. For an InOut mep, here are
>>> the
>>> steps:
>>> * the consumer component create an exchange and send it
>>> through the NMR
>>
>> done
>>
>>> * the NMR select the target endpoint using the metadata and
>>> put it
>>> in the endpoint's component DeliveryChannel
>>> * the component picks the exchange from its DeliveryChannel,
>>> process it by populating the out message, and send it through the
>>> DeliveryChannel
>>
>> done
>>
>>> * the NMR route the exchange back to the consumer component
>>> * the consumer component picks the exchange from its
>>> DeliveryChannel, process the response, set the status to DONE and
>>> sent
>>> it back through the DC
>>
>> Here is where things fail with asynchronous message exchange (send
>> ()) and the Smx Bean. The delivery channel or NMR is sending the
>> ME back to the same Bean just the opposite endpoint (consumer
>> endpoint). This is probably due to the MIRROR member (it is just
>> my guess).
>>
>>> * the NMR route the exchange to the target component
>>> * the target component picks the exchange from its DC and usually
>>> just discard it
>>>
>>> On 10/17/07, Andreas Schaefer (2)
>>> <an...@madplanet.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> I had another look into the JBI specification and looking at the
>>>> Figure 9 I would say that when a Message Exchange (ME) is sent back
>>>> to the NMR it should go back to the Caller. Now what happens is
>>>> that
>>>> when the Target Bean is sending the message back to the NMR through
>>>> the Delivery Channel the message is handled by the Consumer
>>>> Endpoint
>>>> of the Target Bean because of using the Mirror ME. This means at
>>>> the
>>>> end the ME is going back to the Target Bean.
>>>>
>>>> This is what I see:
>>>>
>>>> - - - Source Bean creates ME and sets the Provider as service
>>>> and sends
>>>> it through the Delivery Channel
>>>>
>>>> - - - Provider Endpoint of Target Bean is receiving the ME and
>>>> hands it
>>>> over to its Bean
>>>> - Target Bean is handling the ME, sets the response and
>>>> send the
>>>> message back through the Delivery Channel
>>>> - - - Delivery Channel is handing the ME to the service
>>>> mentioned in
>>>> the Mirror of the given ME
>>>> - - - Consumer Endpoint of Target Bean is receiving the ME and
>>>> hands it
>>>> over to its Bean
>>>> - Target Bean is handling the Response now which I think is
>>>> WRONG
>>>>
>>>> Is there something fundamentally wrong with the general ME handling
>>>> in the asynchronous case? Shouldn't the Mirror inside the ME point
>>>> back to the provider (the one that send the ME originally)? And if
>>>> shouldn't it be set by the Delivery Channel in the send of the
>>>> provider?
>>>>
>>>> Thanks - Andy
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.7 (Darwin)
>>>>
>>>> iD8DBQFHFTecs4gPTNnP0gkRAhlaAJsEUdCmko0bcIXZoI5g/ua0nn1eOwCffMT9
>>>> ZmUe5nTrJ/xl75xz2oJYdts=
>>>> =vnwj
>>>> -----END PGP SIGNATURE-----
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>>
>> iD8DBQFHFWnHs4gPTNnP0gkRAg8RAJ91wQWGvAtljtKUlihC2fGFIq2OhACfQkdA
>> sNM1ANMul8OEBg0EyWqYwhk=
>> =KVZH
>> -----END PGP SIGNATURE-----
>
Re: ServiceMix Bean issues with send()
Posted by "Andreas Schaefer (2)" <an...@madplanet.com>.
Hi Guillaume
I tried something new using the SCRIPT as the provider service rather
than another BEAN. Now I think I see a little bit more what is going
wrong. What is happening is that the response is handled by the
BeanComponent (which is good) but because it is using the MIRROR
member to which it sends the response to it fails because of an
unknown request (it should work because I fix that issue locally).
From my understanding I think the message is properly sent back to
the correct BC/SE, in this case the Bean Component, but because it
uses the MIRROR as the address it sends it to the wrong SU, which in
this case is the SCRIPT SU which is not even a BEAN. It seems to me
that the MIRROR is pointing to the consumer endpoint of the provider
SU rather than the consumer SU. That is my log output:
[Notes Andy]: Here I send the InOut Message to he Provider:
2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
ScriptInOutControllerBean - onMessageExchange() send new ME: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
]
2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
BeanComponent - Created correlation id: ID:
10.250.1.197-115aea91258-2:0
2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
DeliveryChannelImpl - Send ID:10.250.1.197-115aea91258-2:0
in DeliveryChannel{ID:10.250.1.197-115aea91258-0:0}
[Notes Andy]: "AS-LOG" are log statements I added to Smx
2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
DeliveryChannelImpl - AS-LOG, doSend(), ME: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
]
2007-10-17 08:51:53,516 [58-0:0-thread-1] INFO
DeliveryChannelImpl - AS-LOG, doSend(), send exchange to
MIRROR: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: provider
service: {urn:scout}script-receiver-service
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
]
2007-10-17 08:51:53,516 [58-0:0-thread-1] DEBUG
SedaFlow - Called Flow send
2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
SedaQueue -
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@4507ed dequeued
exchange: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: provider
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
]
2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
ScriptComponent - Received exchange: status: Active,
role: provider
2007-10-17 08:51:53,519 [58-0:1-thread-1] DEBUG
ScriptComponent - Retrieved correlation id: ID:
10.250.1.197-115aea91258-2:0
...
[Notes Andy]: Script acknowledgment of the message received which
also sends the message back with a response
Hello, I got an input message <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
2007-10-17 08:51:53,591 [58-0:1-thread-1] DEBUG
DeliveryChannelImpl - Send ID:10.250.1.197-115aea91258-2:0
in DeliveryChannel{ID:10.250.1.197-115aea91258-0:1}
2007-10-17 08:51:53,594 [58-0:1-thread-1] INFO
DeliveryChannelImpl - AS-LOG, doSend(), ME: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: provider
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
[Notes Andy]: As you can see the MIRROR is pointing to the same
provider service just with the ROLE of CONSUMER but this Service is a
SCRIPT and not a BEAN
2007-10-17 08:51:53,596 [58-0:1-thread-1] INFO
DeliveryChannelImpl - AS-LOG, doSend(), send exchange to
MIRROR: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
2007-10-17 08:51:53,596 [58-0:1-thread-1] DEBUG
SedaFlow - Called Flow send
2007-10-17 08:51:53,597 [58-0:1-thread-2] DEBUG
SedaQueue -
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1@aeaea6 dequeued
exchange: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
[Notes Andy]: Correctly the BEAN gets the Message but because of the
wrong Service name in the MIRROR it tries to call the Consumer
endpoint of the provider -> FAILURE
2007-10-17 08:51:53,597 [58-0:1-thread-2] DEBUG
BeanComponent - Received exchange: status: Active,
role: consumer
2007-10-17 08:51:53,598 [58-0:1-thread-2] DEBUG
BeanComponent - Retrieved correlation id: ID:
10.250.1.197-115aea91258-2:0
2007-10-17 08:51:53,600 [58-0:1-thread-2] INFO
BeanComponent - onConsumerExchange(), cor-id: ID:
10.250.1.197-115aea91258-2:0, ME: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
2007-10-17 08:51:53,600 [58-0:1-thread-2] INFO
BeanComponent - AS-LOG, findRequest(), corr-id: ID:
10.250.1.197-115aea91258-2:0, bean:
org.apache.servicemix.bean.BeanComponent@2f717c
2007-10-17 08:51:53,602 [58-0:1-thread-2] ERROR
BeanComponent - Error processing exchange InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
java.lang.IllegalStateException: Receiving unknown consumer exchange:
InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: <?xml version="1.0" encoding="UTF-8"?
><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
out: <?xml version="1.0" encoding="UTF-8"?><world>hello</world>
]
at org.apache.servicemix.bean.BeanEndpoint.onConsumerExchange
(BeanEndpoint.java:274)
The solution seems to be to set the MIRROR to the consumer rather the
provider as it is now. I would think that the DeliveryChannelImpl
should do that when the message is sent by the consumer, right?
Thanks - Andy
On Oct 16, 2007, at 6:47 PM, Andreas Schaefer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Guillaume
>
> If I am not mistaken then there seems to be a problem either in the
> DeliveryChannelImpl or the NMR inside ServiceMix when handling
> asynchronous message exchanges. If you could help understand how
> ServiceMix discovers the consumer Endpoint it has to send a
> response back from the provider I could have a closer look into
> what is going wrong. According to your outline below I did
> everything correctly. If my hunch is correct then the problem is
> symptomatic in Smx and is not limited to the Bean component.
>
> Please see below:
>
> On Oct 16, 2007, at 6:29 PM, Guillaume Nodet wrote:
>
>> You should not care about the mirror stuff, which is internal to
>> ServiceMix. Briefly, each component only see one side of the
>> exchange
>> (while the other one see the mirror). So each time the exchange goes
>> from the consumer to the provider, the mirror exchange is delivered.
>> But components are not aware of that at all.
>
> I don't care about the MIRROR member but I see that this seems to
> be the issue that is causing the problem.
>
>> From a JBI point of view, there are mainly four different meps, each
>> mep being handled in a different way. For an InOut mep, here are the
>> steps:
>> * the consumer component create an exchange and send it through
>> the NMR
>
> done
>
>> * the NMR select the target endpoint using the metadata and put it
>> in the endpoint's component DeliveryChannel
>> * the component picks the exchange from its DeliveryChannel,
>> process it by populating the out message, and send it through the
>> DeliveryChannel
>
> done
>
>> * the NMR route the exchange back to the consumer component
>> * the consumer component picks the exchange from its
>> DeliveryChannel, process the response, set the status to DONE and
>> sent
>> it back through the DC
>
> Here is where things fail with asynchronous message exchange (send
> ()) and the Smx Bean. The delivery channel or NMR is sending the ME
> back to the same Bean just the opposite endpoint (consumer
> endpoint). This is probably due to the MIRROR member (it is just my
> guess).
>
>> * the NMR route the exchange to the target component
>> * the target component picks the exchange from its DC and usually
>> just discard it
>>
>> On 10/17/07, Andreas Schaefer (2) <an...@madplanet.com>
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I had another look into the JBI specification and looking at the
>>> Figure 9 I would say that when a Message Exchange (ME) is sent back
>>> to the NMR it should go back to the Caller. Now what happens is that
>>> when the Target Bean is sending the message back to the NMR through
>>> the Delivery Channel the message is handled by the Consumer Endpoint
>>> of the Target Bean because of using the Mirror ME. This means at the
>>> end the ME is going back to the Target Bean.
>>>
>>> This is what I see:
>>>
>>> - - - Source Bean creates ME and sets the Provider as service and
>>> sends
>>> it through the Delivery Channel
>>>
>>> - - - Provider Endpoint of Target Bean is receiving the ME and
>>> hands it
>>> over to its Bean
>>> - Target Bean is handling the ME, sets the response and send
>>> the
>>> message back through the Delivery Channel
>>> - - - Delivery Channel is handing the ME to the service mentioned in
>>> the Mirror of the given ME
>>> - - - Consumer Endpoint of Target Bean is receiving the ME and
>>> hands it
>>> over to its Bean
>>> - Target Bean is handling the Response now which I think is
>>> WRONG
>>>
>>> Is there something fundamentally wrong with the general ME handling
>>> in the asynchronous case? Shouldn't the Mirror inside the ME point
>>> back to the provider (the one that send the ME originally)? And if
>>> shouldn't it be set by the Delivery Channel in the send of the
>>> provider?
>>>
>>> Thanks - Andy
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (Darwin)
>>>
>>> iD8DBQFHFTecs4gPTNnP0gkRAhlaAJsEUdCmko0bcIXZoI5g/ua0nn1eOwCffMT9
>>> ZmUe5nTrJ/xl75xz2oJYdts=
>>> =vnwj
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHFWnHs4gPTNnP0gkRAg8RAJ91wQWGvAtljtKUlihC2fGFIq2OhACfQkdA
> sNM1ANMul8OEBg0EyWqYwhk=
> =KVZH
> -----END PGP SIGNATURE-----
Re: ServiceMix Bean issues with send()
Posted by Guillaume Nodet <gn...@gmail.com>.
You should not care about the mirror stuff, which is internal to
ServiceMix. Briefly, each component only see one side of the exchange
(while the other one see the mirror). So each time the exchange goes
from the consumer to the provider, the mirror exchange is delivered.
But components are not aware of that at all.
>From a JBI point of view, there are mainly four different meps, each
mep being handled in a different way. For an InOut mep, here are the
steps:
* the consumer component create an exchange and send it through the NMR
* the NMR select the target endpoint using the metadata and put it
in the endpoint's component DeliveryChannel
* the component picks the exchange from its DeliveryChannel,
process it by populating the out message, and send it through the
DeliveryChannel
* the NMR route the exchange back to the consumer component
* the consumer component picks the exchange from its
DeliveryChannel, process the response, set the status to DONE and sent
it back through the DC
* the NMR route the exchange to the target component
* the target component picks the exchange from its DC and usually
just discard it
On 10/17/07, Andreas Schaefer (2) <an...@madplanet.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I had another look into the JBI specification and looking at the
> Figure 9 I would say that when a Message Exchange (ME) is sent back
> to the NMR it should go back to the Caller. Now what happens is that
> when the Target Bean is sending the message back to the NMR through
> the Delivery Channel the message is handled by the Consumer Endpoint
> of the Target Bean because of using the Mirror ME. This means at the
> end the ME is going back to the Target Bean.
>
> This is what I see:
>
> - - - Source Bean creates ME and sets the Provider as service and sends
> it through the Delivery Channel
>
> - - - Provider Endpoint of Target Bean is receiving the ME and hands it
> over to its Bean
> - Target Bean is handling the ME, sets the response and send the
> message back through the Delivery Channel
> - - - Delivery Channel is handing the ME to the service mentioned in
> the Mirror of the given ME
> - - - Consumer Endpoint of Target Bean is receiving the ME and hands it
> over to its Bean
> - Target Bean is handling the Response now which I think is WRONG
>
> Is there something fundamentally wrong with the general ME handling
> in the asynchronous case? Shouldn't the Mirror inside the ME point
> back to the provider (the one that send the ME originally)? And if
> shouldn't it be set by the Delivery Channel in the send of the provider?
>
> Thanks - Andy
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHFTecs4gPTNnP0gkRAhlaAJsEUdCmko0bcIXZoI5g/ua0nn1eOwCffMT9
> ZmUe5nTrJ/xl75xz2oJYdts=
> =vnwj
> -----END PGP SIGNATURE-----
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/