|
|
| Author |
Message |
|
| Guest |
 Posted: Fri Apr 04, 2008 7:04 pm |
 |
|
|
Guest
|
Neil,
Neil Ellis wrote:
> Not sure if this has already been reported; in version 1.2.0 of
> lib-rabbitmq there is a NPE if the publish() method has been called on
> RpcClient because the temp queue picks it up and attempts to call
> setBody() on the blocker. Trivially chaning blocker.set(body) to have a
> NP check fixes this:
>
> if(blocker != null) {
> blocker.set(body);
> }
Why would you call publish() on the RpcClient? You are meant to be using
one of
byte[] primitiveCall(byte[] message)
String stringCall(String message)
Map mapCall(Map message)
Map mapCall(Object[] keyValuePairs)
to perform an RPC.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Apr 04, 2008 7:10 pm |
|
|
|
Guest
|
Hi Matthias
That's just how it's done in the Mule connector, it's making use of
the same client for RPC calls and non RPC calls. I think Tony put that
together so you may want to chat with him, I'm sure Ross would be
happy to change it if there is a better strategy.
Kind regards
Neil
On 4 Apr 2008, at 20:03, Matthias Radestock wrote:
> Neil,
>
> Neil Ellis wrote:
>> Not sure if this has already been reported; in version 1.2.0 of lib-
>> rabbitmq there is a NPE if the publish() method has been called on
>> RpcClient because the temp queue picks it up and attempts to call
>> setBody() on the blocker. Trivially chaning blocker.set(body) to
>> have a NP check fixes this:
>> if(blocker != null)
>> { blocker.set(body);
>> }
>
> Why would you call publish() on the RpcClient? You are meant to be
> using one of
> byte[] primitiveCall(byte[] message)
> String stringCall(String message)
> Map mapCall(Map message)
> Map mapCall(Object[] keyValuePairs)
> to perform an RPC.
>
>
> Matthias.
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Apr 04, 2008 7:50 pm |
|
|
|
Guest
|
Neil,
Neil Ellis wrote:
> That's just how it's done in the Mule connector, it's making use of the
> same client for RPC calls and non RPC calls. I think Tony put that
> together so you may want to chat with him, I'm sure Ross would be happy
> to change it if there is a better strategy.
Actually, using RpcClient.publish should be perfectly safe, if a little
weird and undocumented. I cannot see the publish would end up placing
messages in the reply queue of the same RpcClient. The reply queue is
given a server-generated name and is bound to the default exchange (""),
which is a direct exchange. To send a message to the reply queue it
would have to be sent to the default exchange with a routing key equal
to the generated queue name. Since both the exchange name and routing
key are supplied to the constructor of the RpcClient there is no way for
that to happen.
Instead what I suspect might be causing the problem is an rpc server
replying to a message twice, or perhaps two rpc servers replying to the
same message. Do you think that can occur in your set up?
The arrival of the second reply would indeed trigger an NPE. That's
perhaps not the nicest exception to throw under the circumstances, but
*some* exception is certainly warranted.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
