activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AMQ-2827) Intermittent 204 response using REST
Date Wed, 08 Sep 2010 10:45:42 GMT

     [ https://issues.apache.org/activemq/browse/AMQ-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dejan Bosanac resolved AMQ-2827.
--------------------------------

      Assignee: Dejan Bosanac
    Resolution: Working as Designed

I added a test case that confirms that this scenario works fine. take a look at testCorrelation()
in RestTest

https://svn.apache.org/repos/asf/activemq/trunk/activemq-web-demo/src/test/java/org/apache/activemq/web/RestTest.java

Also note, that you need to set clientId on your GET url in order to use the same consumer
every time and get all messages.

> Intermittent 204 response using REST
> ------------------------------------
>
>                 Key: AMQ-2827
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2827
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.4.0
>         Environment: Linux
> JDK5
>            Reporter: Michael Lok
>            Assignee: Dejan Bosanac
>         Attachments: MQRESTClient.java, restclient.java
>
>
> Was able to successfully send 20 messages to AMQ via REST.  I can see that the messages
were consumed and there are 20 messages in the response queue.  However, when reading the
response queue using selector via REST, it intermittently returns HTTP code 204.  By looking
at the "Active Consumers" for the response queue, I can see that the specific message has
been dispatched to the consumer as the "Enqueues", "Dequeues" and "Dispatched" values are
set to 1.
> The server has been configured with consumer.prefetchSize=1.
> I've further tried reproducing the problem by setting consumer.prefetchSize=0.  When
I get a 204 response, I can see that the message is in the outgoing queue.  But executing
another GET with the same Correlation ID will hang the client even though readTimeout is set.
> This has been tested with 5.4-SNAPSHOT 15-July.
> Update 23 July:
> Tried using the following settings:
> - removed consumer.prefetchSize in web.xml
> - saved session cookie for requests
> - used the "selector" HTTP header
> - used a random value for clientId in each request
> It seems to be returning all messages in properly.  However, each request generates a
new client session based on the selector header.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message