<div>Hello,</div>
<div>�</div>
<div>@ Mysurf: I asked almost the same questions about two weeks ago (&quot;questions about RpcClient&quot;)</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 &quot;single request / multiple replies&quot; 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">&lt;<a href="mailto:steve@rabbitmq.com">steve@rabbitmq.com</a>&gt;</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 &#39;callbacks&#39; 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>&#39;Using the RpcClient from different threads&#39; is probably a little more tricky.<br>However, publishes use the channel interface so ought to be OK, although all<br>
RpcClient &#39;calls&#39; 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.) &#39;Would you like peas with that?&#39;<br>distribute (v.) To denigrate an award ceremony.<br>
definite (phr.) &#39;It&#39;s hard of hearing, I think.&#39;<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>&gt; 1. Is it ok to use the same channel from different threads?<br>&gt; 2. Is it ok to use RPC client from different threads<br>&gt; [I am trying to narrow down on the cause of my problems (usage of close rpc queue). ]<br>
</div></div>&gt; _______________________________________________<br>&gt; rabbitmq-discuss mailing list<br>&gt; <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>&gt; <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>