[Remoting] - Re: forceRemote timeout Problems
by ron.sigal＠jboss.com
Hi Markus,
When a Remoting client and server are in the same JVM, the client will, by default, make a method call directly on the server instead of marshalling and unmarshalling invocations over a pair of sockets. For example,
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:853)
| at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
| at org.jboss.remoting.Client.invoke(Client.java:1640)
|
shows Client.invoke() calling LocalClientInvoker.invoke(), which calls ServerInvoker.invoke(). If the server were in a different JVM, you would see Client.invoke() calling BisocketClientInvoker.invoke(), followed by a sequence of calls ending with a socket write.
By setting the "force_remote" parameter to true, you are telling Remoting to avoid the network bypass and call BisocketClientInvoker. That's OK, but when you add
| <attribute name="force_remote">true</attribute>
|
to the MBean configuration, you're setting "force_remote" on the server but not the client. You want to add 'isParam="true"':
| <attribute name="force_remote" isParam="true">true</attribute>
|
which adds "force_remote=true" to the InvokerLocator. The client then gets the "force_remote" parameter from the InvokerLocator. I think that should solve your timeout problem.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219627#4219627
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219627
17 years, 1 month
[EJB/JBoss] - MDB 'at most, once' delivery (Ack before onMessage)
by azda
Is there any way to set up the MDB container to send an acknowledgment before it calls onMessage? (I'm currently using EJB 3, but I don't think this is an EJB 3 specific question. The app server is 5.0.1GA)
This seems like a fairly straight forward delivery pattern (guarantee the message was received, but not necessarily that any work was completed. a.k.a 'at most, once'). I'm having problems figuring out if JEE supports this, or I'm just missing the right combination of settings.
Here are my requirements:
1.) I don't need a transaction
2.) A message should be processed 'at most, once' (it doesn't matter if the MDB acks and crashes before calling onMessage, thus loosing the message, as long as no duplicates are delivered)
I've set up:
TransactionManagementType.BEAN, TransactionAttributeType.NOT_SUPPORTED for onMessage, acknowledgeMode=Auto-acknowledge,
as well as MaxDeliveryAttempts=1 on the Queue
I read somewhere that this configuration would get me what I want (maybe for another app server?). It doesn't.
1.) Ack isn't until onMessage completes
2.) If the app server crashes (I simulated by just killing the JVM), when it comes back up, the messages that were processing when the crash occurred, get re-delivered (even though I have MaxDeliveryAttempts at 1)!
The behavior of 2 is what I would expect with acknowledgeMode=Dups-ok-acknowledge. I've read that this mode has the feature of not waiting till onMessage finishes to ack, but you can't guarantee when. So you have to deal with the possibility of duplicates.
In Summary: I'd rather not have to deal with detecting duplicates, and it seems easy enough to do, if the container would just ack before onMessage. Is this possible, or am I just wishfully thinking?
-Az
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219610#4219610
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219610
17 years, 1 month