activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (Commented) (JIRA)" <jira+amq...@apache.org>
Subject [jira] [Commented] (AMQNET-377) Sending to non-existent temp queue causes consumer to shutdown
Date Thu, 12 Apr 2012 18:37:22 GMT

    [ https://issues.apache.org/jira/browse/AMQNET-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252702#comment-13252702
] 

Timothy Bish commented on AMQNET-377:
-------------------------------------

You need the AlwaysSyncSend because that's the only way you get an exception response back
for the send otherwise the error comes back as a broker error.  The sleep is to give the broker
time to deal with the removal of the connection and its associated resources, which is needed
in the test because we want the next send to fail deterministically.  If you didn't sleep
its entirely possible that the reply producer send which is using a different connection could
sneak in the send before the other connection's transport connection finishes processing the
remove of the connection, this is somewhat dependent though on your brokers configuration
on whether its using dedicated task runners or not.  
                
> Sending to non-existent temp queue causes consumer to shutdown
> --------------------------------------------------------------
>
>                 Key: AMQNET-377
>                 URL: https://issues.apache.org/jira/browse/AMQNET-377
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ
>    Affects Versions: 1.5.3, 1.5.4
>         Environment: .NET client on Windows Server 2008 R2
>            Reporter: Chris Robison
>            Assignee: Jim Gomes
>            Priority: Blocker
>         Attachments: 2012-04-09.log, AMQ-NMS.zip, NonExistentTempQueueSendTest.cs, activemq.xml,
putty.log
>
>
> It appears as though attempting to send a message to a non-existent temp queue is causing
the consumer to shutdown. The behavior manifests itself by either the consumer ceasing to
consume messages or, if a request timeout is set, a RequestTimedOutException being thrown.
I have an NUnit project attached that I was able to reproduce the issue with. I've also attached
logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message