<div>Hello,</div>
<div> </div>
<div>@ Mysurf: I asked almost the same questions about two weeks ago ("questions about RpcClient")</div>
<div> </div>
<div>@ Steve: Nice to see that you are working on improving these classes. I actually had three major issues with RpcClient:</div>
<div>- the lack of interface which made mocking quite difficult for unit testing (I had to inherit from the class)</div>
<div>- the fact that the routing key is a final attribute of the class (which makes me create multiple clients when using several routing keys)</div>
<div>- the lack of a "single request / multiple replies" scenario (with a expected number of replies and a timeout)</div>
<div> </div>
<div>John</div>
<div><br> </div>
<div class="gmail_quote">2011/12/5 Steve Powell <span dir="ltr"><<a href="mailto:steve@rabbitmq.com">steve@rabbitmq.com</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br>Since Rabbitmq 2.7.0 it has been possible to use a channel from multiple<br>threads in the Java client, however doing so may block one or other of the<br>
threads if you are using a synchronous command.<br><br>Since consumers now run their 'callbacks' on threads separate from the channel<br>and connection threads, it is now possible to call the channel from within<br>
these callbacks, without deadlocking. Again, you should understand the<br>threading implications.<br><br>'Using the RpcClient from different threads' is probably a little more tricky.<br>However, publishes use the channel interface so ought to be OK, although all<br>
RpcClient 'calls' will be serialised, of course.<br><br>We are currently looking to enhance the RpcClient/Server code, to make them<br>more flexible (being able to call several servers from one client, for example)<br>
and re-usable (reducing the interface and making it more basic), building it on<br>the standard interface, rather than using the implementation classes (as it<br>does now). We are, of course, interested in any problems you detect with the<br>
current RpcClient/Server implementations.<br><br>Steve Powell (a christmas bunny)<br>----------some more definitions from the SPD----------<br>avoirdupois (phr.) 'Would you like peas with that?'<br>distribute (v.) To denigrate an award ceremony.<br>
definite (phr.) 'It's hard of hearing, I think.'<br>modest (n.) The most mod.<br>
<div>
<div></div>
<div class="h5"><br>On 5 Dec 2011, at 10:13, Mysurf Mail wrote:<br><br>> 1. Is it ok to use the same channel from different threads?<br>> 2. Is it ok to use RPC client from different threads<br>> [I am trying to narrow down on the cause of my problems (usage of close rpc queue). ]<br>
</div></div>> _______________________________________________<br>> rabbitmq-discuss mailing list<br>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br>_______________________________________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br>