Sorry for the delay, I will take a look at that today.

On 10/10/07, Andreas Schaefer <[EMAIL PROTECTED]> wrote:
> Digging a little bit deeper and checking what the differences are between
> send() and sendSync() I figured out that sendSync() is swallowing the DONE
> message in
>  DeliveryChannelImpl.processInBound()
>
> with this comment (3.1-incubating):
>
>         // Check if the incoming exchange is a response to a synchronous
> exchange previously sent
>         // In this case, we do not have to queue it, but rather notify the
> waiting thread.
>         if (me.getSyncState() ==
> MessageExchangeImpl.SYNC_STATE_SYNC_SENT) {
>             // If the mirror has been delivered using push, better wait
> until
>             // the push call return.  This can only work if not using
> clustered flows,
>             // but the flag is transient so we do not care.
>             /*if (!me.getMirror().isPushDelivery())*/ {
>                 // Ensure that data is uptodate with the incoming exchange
> (in case the exchange has
>                 // been serialized / deserialized by a clustered flow)
>                 suspendTx(original);
>
> me.setSyncState(MessageExchangeImpl.SYNC_STATE_SYNC_RECEIVED);
>                 notifyExchange(original, original,
> "processInboundSynchronousExchange");
>             }
>             return;
>         }
>
> This makes sure that the DONE message is not sent back to the BeanEndpoint
> and the test for the availability of the request is never made.
>
> Therefore I just changed the BeanEndpoint.process() method to ignore DONE
> messages for consumers and everything worked without an exception:
>
>     @Override
>     public void process(MessageExchange exchange) throws Exception {
>         if (exchange.getRole() == Role.CONSUMER) {
>             if( exchange.getStatus() == ExchangeStatus.DONE ) {
>                 return;
>             }
>             onConsumerExchange(exchange);
>         // Find or create the request for this provider exchange
>         } else if (exchange.getRole() == MessageExchange.Role.PROVIDER) {
>             onProviderExchange(exchange);
>         } else {
>             throw new IllegalStateException("Unknown role: " +
> exchange.getRole());
>         }
>     }
>
> I don't know if this is the right way but it did the trick.
>
> -Andy
>
>
>
>
> On Oct 10, 2007, at 11:11 AM, Andreas Schaefer wrote:
>
> On a side note the checkEndOfRequest() method would make a static requests
> Map fail down the road because it is removing a request after the message is
> handled but most likely before the DONE message is handled.
>
>
> -Andy
>
> On Oct 10, 2007, at 11:06 AM, Andreas Schaefer wrote:
> Hi Guillaume
>
> I found two things that may contribute to this problem in the BeanEndpoint
> class:
>
> 1) When a message is set to DONE and is sent back then the role switches
> from Provider to Consumer. I don't know if that is correct but it then leads
> to the problem.
> 2) The onConsumerExchange() method it only checks if the Request is
> available in the "requests" Map. But when the message is sent asynchronously
> then the DONE message is handled by another BeanEndpoint instance making it
> impossible to find the request in the Map.
>
> I don't know whey the onConsumerExchange() method must match the request but
> either the requests Map must be static or this must only be enforced for
> synchronous calls.
>
>
> Andreas Schaefer
> CEO of Madplanet.com Inc.
> [EMAIL PROTECTED]
>
>
> On Oct 9, 2007, at 10:34 PM, Guillaume Nodet wrote:
>
> I suppose this is related to this bug.  Have you tried the workaround ?
> I'm not quite sure how to solve the problem yet...
>
> On 10/10/07, Andreas Schaefer <[EMAIL PROTECTED]> wrote:
> Hi Geeks
>
> I was trying to use Robust In Only with ServiceMix-Bean but I always get an
> exception when I send the message back as Done. It found this JIRA issue:
> https://issues.apache.org/activemq/browse/SM-944 but it is
> not implemented in 3.1.2 and so I was wondering what is going on and what is
> the cause.
>
> This exceptions were created with 3.1.2:
>
> 2007-10-09 20:54:38,849 [1b-0:0-thread-3] ERROR BeanComponent
>   - Error processing exchange RobustInOnly[
>   id: ID:192.168.0.11-115880c5d1b-2:0
>   status: Done
>   role: consumer
>   service: {urn:scout}receiver-service
>   endpoint: receiver
>   operation: IdontCare: 0
>   in: <?xml version="1.0"
> encoding="UTF-8"?><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> ]
> java.lang.IllegalStateException: Receiving unknown consumer exchange:
> RobustInOnly[
>   id: ID:192.168.0.11-115880c5d1b-2:0
>   status: Done
>   role: consumer
>   service: {urn:scout}receiver-service
>   endpoint: receiver
>   operation: IdontCare: 0
>   in: <?xml version="1.0"
> encoding="UTF-8"?><receiver><title>DontCareEvenMore</title><index>0</index></receiver>
> ]
>         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)
>
> Thanks
>
>
> Andreas Schaefer
> CEO of Madplanet.com Inc.
> [EMAIL PROTECTED]
>
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
>
>
>


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

Reply via email to