[
https://jira.jboss.org/jira/browse/JBESB-2758?page=com.atlassian.jira.plu...
]
Kevin Conner commented on JBESB-2758:
-------------------------------------
The issue is not that the ReplyTo header is invalid, as it is still contains the correct
EPR.
The issue is caused by cleanup code which has been added to ServiceInvoker, however this
code completely ignores whether the current invocation is using the reply to or not. As a
consequence, any async delivery of the message will cause the delivery of the response to
fail, whether or not this is done by a different service.
ReplyTo header is invalid after static router with InVM
-------------------------------------------------------
Key: JBESB-2758
URL:
https://jira.jboss.org/jira/browse/JBESB-2758
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.4 CP3
Reporter: Martin Vecera
Attachments: invm_route.tar.bz2
I have two services in a single ESB archive. Both have set invmScope="GLOBAL",
the first service is accessible via EBWS and routes the message to the second service. The
client awaits a response, which should be sent by the second service to a thread that
executes EBWS servlet. Instead of this and exception is thrown.
2009-07-22 08:30:43,550 ERROR
[org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] Failed to send reply to
address InVMEpr [ PortReference < <wsa:Address invm://thread-910-3/
>, <wsa:ReferenceProperties jbossesb:passByValue : false/> > ] for message
header: [ To: InVMEpr [ PortReference < <wsa:Address invm://thread-910-3/>,
<wsa:ReferenceProperties jbossesb
:passByValue : false/> > ] From: InVMEpr [ PortReference < <wsa:Address
invm://526f757465725465737424242424242424242424242445425753526f757465/false?false#10000/>,
<wsa:ReferencePropert
ies jbossesb:passByValue : false/>, <wsa:ReferenceProperties jbossesb:type :
urn:jboss/esb/epr/type/invm/> > ] RelatesTo: b013fa7a-18ac-40ef-bac5-7ad3ef2c6c5b ]
org.jboss.soa.esb.couriers.CourierException: No deliverAsync courier
at
org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:170)
at
org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.messageTo(ActionProcessingPipeline.java:835)
at
org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.replyTo(ActionProcessingPipeline.java:757)
at
org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:687)
at
org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574)
at
org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408)
at
org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
When an JMS queue is configured in the first service, everything works like a charm.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira