[rabbitmq-discuss] NPE in RpcClient

Sat Mar 15 18:49:00 GMT 2008

Hi Ross,

Yeah, guessed you might be busy! I did (bar the NPE mentioned at the  
bottom) get the connector working in sync.

I'm going to be back on this properly tomorrow and will detail  
further. However in summary I'm using async on the connector so it's  
calling the RPCClient.publish() method. When I have one instance call  
another it was working okay, when I introduced a third node so that A  
calls B and B calls C I'm getting connection closed errors when the  
exchange is started (i.e. on startup). I'll reset any local hacks on  
the connector tomorrow and send the stack traces back to this list.

If we could get a fixed release together (presuming it's not my screw  
up!!!!!) between us that would be great as I am working on a Mule 
+RabbitMQ+Newton article and we might be able to squeeze that out  
prior to MuleCon if there is the will.

Kind regards
Neil

On 15 Mar 2008, at 18:35, Ross Mason wrote:

> Hi Neil,
>
> This does sound interesting.  There is still a fair way to go on the  
> Mule Rabbit Transport, but there are some simple use cases that work.
> What is the problem you have with A -> B -> C? is it that the  
> message doesn't get to C? If so, Are you trying to perform an RPC  
> call from A? (i.e.  RPC from A to get a response from C via B).
>
> BTW Guys, I would like to do a Beta release of the Rabbit Connector  
> before MuleCon, but right now I snowed under this weekend.
>
> Cheers,
>
> Ross Mason
> CTO, Co-Founder
> MuleSource Inc.
>
> http://mulesource.com | http://blog.rossmason.com
>
>
>
> On 15 Mar 2008, at 17:22, Neil Ellis wrote:
>
>> Hi Alexis
>>
>> No probs.
>>
>> Alas I don't have the budget for jet-setting :-(
>>
>> I've been having problems with getting the Mule connector to  
>> handle  A->B->C messages although A->B seems okay. If anyone from  
>> the RabbitMQ side could give me a little hand on getting it up and  
>> running that would be fabulous - I'm pretty busy at the moment  
>> between this work and project:Einstein/deesel ( http://einstein.codecauldron.org 
>>  / http://deesel.codecauldron.org ) so any help would increase the  
>> chances of having a demo ready for you.
>>
>> I've restructured the current demo to show
>>
>> 1 Polller Mule instance reading from an RSS feed.
>> 3-5 Worker Mule instances transforming the feed (at least a  
>> notional idea of work).
>> 1 Displayer Mule instance displaying the transformed results to the  
>> screen.
>>
>> It's a bit noddy but it shows how Newton can distribute a set of  
>> Mule nodes based upon simple criteria, so on a single Newton  
>> instance you would have all the Mule instances at the same time on  
>> one instance, on 7 instances you would have 1 poller, 3-5 workers  
>> and 1 displayer - and in between it scales appropriately. And then  
>> shows RabbitMQ as the internode protocol. We could easily turn this  
>> into a demo of running RabbitMQ on a large number of nodes with  
>> super-easy deployment and failover in the future - that's something  
>> to think about.
>>
>> We could certainly help with providing materials (i.e. slides or  
>> user guide) and help getting you running the demo before hand - in  
>> return would you be able to ensure that Paremus/myself get  
>> appropriate credit at the demo for our part (i.e. powered by Newton  
>> and the appropriate links)?
>>
>> Anyway let us know - I'm on Skype most of the time - I think you  
>> have me as a contact (neilellis).
>>
>> All the best
>> Neil
>>
>>
>> On 15 Mar 2008, at 12:16, Alexis Richardson wrote:
>>
>>> Neil
>>>
>>> Thank-you very much.  That sounds like a really interesting demo.
>>> Please let us know how you get on.  Also - will you be at  
>>> MuleCon?  I
>>> am going and would love to show anything you have to folks at the
>>> conference.
>>>
>>> alexis
>>>
>>>
>>> On Thu, Mar 13, 2008 at 5:48 PM, Neil Ellis <neil.ellis at mangala.co.uk 
>>> > wrote:
>>>> Hi Folks
>>>>
>>>> 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);
>>>>                }
>>>>
>>>> This was line 150 of RpcClient. I've cc-ed the list for the mule
>>>> transport as it is the mule transport using publish() that caused  
>>>> my
>>>> problem.
>>>>
>>>> Btw. The website for the work I'm doing is http://mule4newton.codecauldron.org/mule4newton-examples/mule4newton-rabbitmq/index.html
>>>> and the src is at http://svn.codecauldron.org/mule4newton/trunk/examples/rabbitmq/
>>>> - basically we're combining Newton, Mule and RabbitMQ as an
>>>> illustration of a flexible open-source based messaging system.
>>>>
>>>> Kind regards
>>>> Neil
>>>>
>>>>
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> Alexis Richardson
>>> +44 20 7617 7339 (UK)
>>> +44 77 9865 2911 (cell)
>>> +1 650 206 2517 (US)
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2431 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080315/76be2d7f/attachment.bin 