List Info

Thread: ServiceMix Bean issues with send()
ServiceMix Bean issues with send()
user name
 2007-10-15 17:24:29 

  


  

    Hi

I try to figure out what is going wrong with the ServiceMix Bean component when used with an asynchronous message exchange (send()). There is a good chance to I do not understand how the message exchange should work. This is what I tried:

- Bean SU 1 sends an In-Out ME to another Bean SU 2 with send() on the Delivery Channel
- B SU 2 handles the message and puts in an Out normalized message and then sends the ME back with send() on its Delivery Channel

What I see is that the Delivery Channel is sending the "Mirror" ME which is nearly the same but just has the opposite role (here "consumer"). This means that the message is sent back to the Consumer Bean Endpoint because that is the address set in the Mirror ME.

Is my assumption right that when a message is read from the NMR that it goes through the Provider endpoint and when the message is sent back that it then goes first through the Consumer endpoint of the same service or should it go to the Consumer endpoint of the calling service?
If the consumer endpoint of he SAME service is called then who is responsible on sending the message back to the calling service (B SU 1) and is there a way to do this automatically (meaning with having to code anything in the Bean SUs)?

Thank you

 
Andreas Schaefer
CEO of Madplanet.com Inc.
 andreas.schaefermadplanet.com">andreas.schaefermadplanet.com

 


  

  
  
   
     
    

  

    Re: ServiceMix Bean issues with send()
  


  

     user name

     2007-10-15 20:06:14
  


  

    
On 10/16/07, Andreas Schaefer (2) <andreas.schaefermadplanet.com> wrote:
> Hi
>
> I try to figure out what is going wrong with the
ServiceMix Bean component
> when used with an asynchronous message exchange
(send()). There is a good
> chance to I do not understand how the message exchange
should work. This is
> what I tried:
>
> - Bean SU 1 sends an In-Out ME to another Bean SU 2
with send() on the
> Delivery Channel
> - B SU 2 handles the message and puts in an Out
normalized message and then
> sends the ME back with send() on its Delivery Channel
>
> What I see is that the Delivery Channel is sending the
"Mirror" ME which is
> nearly the same but just has the opposite role (here
"consumer"). This means
> that the message is sent back to the Consumer Bean
Endpoint because that is
> the address set in the Mirror ME.

Yeah.  The thing is that in JBI, an exchange is sent from a
component
to an endpoint.  In an InOut mep, the provider will send the
exchange
with the out message inside, the nmr will route it to the
consumer
component, which will dispatch it to the consumer endpoint. 
The
endpoint processes the response and need to send back the
exchange
with a DONE status.  The mirror stuff is used internally.

>
> Is my assumption right that when a message is read from
the NMR that it goes
> through the Provider endpoint and when the message is
sent back that it then
> goes first through the Consumer endpoint of the same
service or should it go
> to the Consumer endpoint of the calling service?

I don't understand what is the difference you make between
"Consumer
endpoint of the same service" and " Consumer
endpoint of the calling
service" ? Do you mean the POJO instance ?

> If the consumer endpoint of he SAME service is called
then who is
> responsible on sending the message back to the calling
service (B SU 1) and
> is there a way to do this automatically (meaning with
having to code
> anything in the Bean SUs)?
>

If you don't implement MessageExchangeListener and you want
to use
InOut asynchronously, then you need to use the Callback
annotation
and the Destination.

Else, I think the problem is that the component does not
track that a
given endpoint acts as a consumer and send an exchange, so
that it can
not route it back to the endpoint.  This would require
wrapping the
DeliveryChannel or simply overriding the
sendConsumerExchange method
from the component.  All exchanges sent from endpoints could
be
tracked, but we still don't have any way to call the bean,
unless it
has a Callback.

Can you post your beans, because servicemix-bean has
different ways of
writing a bean, so...

> Thank you
>
>
> Andreas Schaefer
> CEO of Madplanet.com Inc.
> andreas.schaefermadplanet.com
>
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.co
m/



  


  

    
  

  
  
   
     
    

  

    Re: ServiceMix Bean issues with send()
  


  

     user name

     2007-10-17 17:42:17
  


  

    

  


  

    
 
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>&lt;/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>&lt;/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>&lt;/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$14507ed 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>&lt;/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>&lt;/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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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$1aeaea6 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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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.BeanComponent2f717c
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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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) < andreas.schaefermadplanet.com">andreas.schaefermadplanet.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
------------------------
 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHFWnHs4gPTNnP0gkRAg8RAJ91wQWGvAtljtKUlihC2fGFIq2OhACfQkdA
sNM1ANMul8OEBg0EyWqYwhk=
=KVZH
-----END PGP SIGNATURE-----
 



  

  
  
   
     
    

  

    Re: ServiceMix Bean issues with send()
  


  

     user name

     2007-10-18 13:36:50
  


  

    

  


  

    
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: {urnTest}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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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$1bc4e89 dequeued exchange: InOut[
  id: ID:10.250.1.197-115b42ceaed-2:0
  status: Active
  role: consumer
  service: {urnTest}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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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: {urnTest}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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;hello</world>
]
java.lang.IllegalStateException: Receiving unknown consumer exchange: InOut[
  id: ID:10.250.1.197-115b42ceaed-2:0
  status: Active
  role: consumer
  service: {urnTest}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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/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>&lt;/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>&lt;/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$14507ed 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>&lt;/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>&lt;/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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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$1aeaea6 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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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.BeanComponent2f717c
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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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>&lt;/receiver>
  out: <?xml version="1.0" encoding="UTF-8"?><world&gt;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) < andreas.schaefermadplanet.com">andreas.schaefermadplanet.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
------------------------
 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHFWnHs4gPTNnP0gkRAg8RAJ91wQWGvAtljtKUlihC2fGFIq2OhACfQkdA
sNM1ANMul8OEBg0EyWqYwhk=
=KVZH
-----END PGP SIGNATURE-----
 




  

  
  
   
     
    

  

    Re: ServiceMix Bean issues with send()
  


  

     user name

     2007-10-18 19:56:54
  


  

    
-----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+uGgBjIN0i3zQCf
ceDi
rdw1L46NBoZnzqQzLYILOEw=
=VDq2
-----END PGP SIGNATURE-----



  


  

    
  

  
  
   
     
    

  

    Re: ServiceMix Bean issues with send()
  


  

     user name

     2007-10-19 04:48:05
  


  

    
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) <andreas.schaefermadplanet.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+uGgBjIN0i3zQCf
ceDi
> rdw1L46NBoZnzqQzLYILOEw=
> =VDq2
> -----END PGP SIGNATURE-----
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.co
m/



  


  

    
  

  
  
   
     
    

  

    Re: ServiceMix Bean issues with send()
  


  

     user name

     2007-10-19 10:02:42
  


  

    
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)
<andreas.schaefermadplanet.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()
  


  

     user name

     2007-10-19 10:29:06
  


  

    
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 <andreas.schaefermadplanet.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)
<andreas.schaefermadplanet.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.co
m/



  


  

    
  

  
  
   
     
    






 [1-8]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )