thanks guillaume,
will switch to jms for remote synchronous calls.
cheers,
j.
On 10/4/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
On 10/4/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
>
> that said, in-out mep's are effectively a request/response pattern
> even if they're done asynchronously. so if you have a client that's
> turning a method call into an in-out mep to a remote endpoint and you
> want it to be transactional (or as transactional as possible) as in
> this pseudo code:
>
> Response doSomethingImportant(Request) {
> begin transaction
> async send in-out mep to remote SM endpoint;
> end transaction?
> wait for response;
> return response;
> }
>
> doesn't that imply you need to corellate the results (just on
> exchange.getExchangeId())?
I doubt this would be a good thing to do.
The reason is that your method is no more transactional.
If the message has been sent in a transaction, it will be
delivered (or re-routed if you use a dead letter queue).
But in your case, another exchange will be sent.
If you want synchronous remote exchange, just don't use
transactions. If you need transactions, you can use
sync (on seda) or async (on jca), but if you use async,
you need to be fully asynchronous:
void doSomehtingImportant(Request) {
begin tx
send request
commit tx
}
void doSomethingImportantResponse(Response) {
handleResponse
}
>
> cheers,
> j.
>
> >
> > >
> > > i think for the moment i'm going to require jms flow. would it be
> > > possible to add jmsflow as one of the flows in the default servicemix
> > > delivery so that synchronous remote calls are supported?
> >
> > Sure.
> >
> > >
> > > cheers,
> > > j.
> > >
> > > On 10/4/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > I have just spotted that the first test you wrote should not work.
> > > > SendSync can not be used on top of the JCA flow, as there is
> > > > no way to do synchronous request / response calls with JMS.
> > > > See http://servicemix.goopen.org/site/transactions.html
> > > >
> > > > I need to fix the JCA flow to reject synchronous calls.
> > > >
> > > >
> > > > On 10/4/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > hiya,
> > > > >
> > > > > JCAFlow still seems to be misbehaving for me. I get the following
> > > > > kinds of behaviour using a component deployed into a default SM
> > > > > container and an integration test:
> > > > >
> > > > > some success at first
> > > > > count not find route for exchange
> > > > > message passed to component but reply not received
> > > > > endpoint found but message not passed to component
> > > > >
> > > > > it's difficult to debug in the container but this keeps popping up:
> > > > >
> > > > > DEBUG [Thread-5] ServerSessionImpl:1.run(167) | Endpoint failed to
> > > > > process message.
> > > > > java.lang.RuntimeException: Endpoint after delivery notification
failure
> > > > > at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:216)
> > > > > at
org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
> > > > > at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
> > > > > at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291)
> > > > > at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
> > > > > at java.lang.Thread.run(Thread.java:595)
> > > > > Caused by: java.lang.IllegalStateException: Cannot commit if the
> > > > > transaction is not bound to the current thread
> > > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionDelegate.commit(GeronimoTransactionDelegate.java:49)
> > > > > at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
> > > > > at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:125)
> > > > > at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:64)
> > > > > at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:214)
> > > > > ... 5 more
> > > > >
> > > > > and i can replicate it in a test (pretty much the same test as for the
> > > > > last issue, just sending 2 messages instead of 1). neither the
> > > > > component or the defaultservicemixclient is doing anything explicitly
> > > > > with transactions.
> > > > >
> > > > > I'm running with ServiceMix 3.0
> > > > >
> > > > > should I raise it in JIRA?
> > > > >
> > > > > cheers,
> > > > > j.
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
--
Cheers,
Guillaume Nodet
