<div dir="ltr"><div><div style>I think it&#39;s a problem of this particular instance. I&#39;ve downgraded RabbitMQ to 2.8.7, and still have same�behavior�- no reaction to invalid action, no errors at all.</div></div><div style>

<br></div><div style>I&#39;ve checked RabbitMQ logs - nothing related to my actions.</div><div style><br></div><div style>I&#39;ve executed &quot;rabbitmqctl status&quot; to ensure that version is correct:</div><div style>

<br></div><div style><div>�rabbitmqctl status</div><div>Status of node &#39;rabbit@ip-10-182-22-183&#39; ...</div><div>[{pid,30523},</div><div>�{running_applications,[{rabbit,&quot;RabbitMQ&quot;,&quot;2.8.7&quot;},</div>

<div>� � � � � � � � � � � � {os_mon,&quot;CPO �CXC 138 46&quot;,&quot;2.2.10&quot;},</div><div>� � � � � � � � � � � � {sasl,&quot;SASL �CXC 138 11&quot;,&quot;2.2.1&quot;},</div><div>� � � � � � � � � � � � {mnesia,&quot;MNESIA �CXC 138 12&quot;,&quot;4.7.1&quot;},</div>

<div>� � � � � � � � � � � � {stdlib,&quot;ERTS �CXC 138 10&quot;,&quot;1.18.2&quot;},</div><div>� � � � � � � � � � � � {kernel,&quot;ERTS �CXC 138 10&quot;,&quot;2.15.2&quot;}]},</div><div>�{os,{unix,linux}},</div><div>

�{erlang_version,&quot;Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:30] [hipe] [kernel-poll:true]\n&quot;},</div><div>�{memory,[{total,27509232},</div><div>� � � � � {processes,10481394},</div><div>

� � � � � {processes_used,10481380},</div><div>� � � � � {system,17027838},</div><div>� � � � � {atom,504409},</div><div>� � � � � {atom_used,476697},</div><div>� � � � � {binary,640152},</div><div>� � � � � {code,11973387},</div>

<div>� � � � � {ets,823696}]},</div><div>�{vm_memory_high_watermark,0.4},</div><div>�{vm_memory_limit,3221225472},</div><div>�{disk_free_limit,1000000000},</div><div>�{disk_free,267063296},</div><div>�{file_descriptors,[{total_limit,924},</div>

<div>� � � � � � � � � � {total_used,4},</div><div>� � � � � � � � � � {sockets_limit,829},</div><div>� � � � � � � � � � {sockets_used,2}]},</div><div>�{processes,[{limit,1048576},{used,127}]},</div><div>�{run_queue,0},</div>

<div>�{uptime,173}]</div><div>...done.</div><div><br></div></div><div dir="ltr"><div class="gmail_extra" style><br></div><div class="gmail_extra" style>Is there anything else I can check?</div><div class="gmail_extra"><br>

<br><div class="gmail_quote">2013/1/17 Matthias Radestock <span dir="ltr">&lt;<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On 17/01/13 23:04, Dmitriy Bannikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;ve created a test Java class which tries to publish message into a<br>
fake queue.<br>
In Windows this message is failing, and ReturnListener shows it&#39;s<br>
output. In Linux there&#39;re not error or fails.<br>
<br>
I&#39;ve just upgraded rabbitmq from 2.8.6 to 3.0.1 on both WIndows and<br>
Linux machines.<br>
<br>
Code is following: �[...]<br>
� � � � �channel.basicPublish(&quot;&quot;, &quot;fake_queue_112233&quot;, true, true,<br>
props, &quot;Test String&quot;.getBytes());<br>
</blockquote>
<br>
That call has the &#39;immediate&#39; flag set. The RabbitMQ server stopped supporting that in 3.0.0, so the above will result in an connection-level error.<br>
<br>
But since publishing is asynchronous, a client won&#39;t see that error unless it a) stays around long enough for the error to arrive, and b) either performs some other action on the channel or has an appropriate error handler (in case of the Java client a ShutdownListener) configured on the channel. Since the basicPublish is the last thing your program does, and no handler is installed, the error won&#39;t show up. And since the error that is generated is a connection level error, the connection will be closed and the program terminates. If you, say, added a connection.close() at the end of your program, you&#39;d get an error.<br>


<br>
Now, if you were just setting mandatory, or running 2.8.6 (where &#39;immediate&#39; doesn&#39;t result in an error) then the return listener should get invoked. And since a return is a not an error, the connection will stay alive and the program won&#39;t terminate. Indeed all that happens for me, on Linux, when I try it.<br>


<br>
As to why this would behave differently on windows and linux, I suspect the upgrade of the broker didn&#39;t actually happen on the former, so it&#39;s still running 2.8.6.<br>
<br>
Regards,<br>
<br>
Matthias.<br>
</blockquote></div><br></div></div></div>