You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by chinshaw <ch...@gmail.com> on 2014/04/07 23:25:04 UTC
Lengthy delays when using ActiveMQ Ajax Client
I posted this earlier on stackoverflow.com but this may be a better place to
get some advice.
I think my question simplified is should messages be received by the browser
before the end of the timeout because if a message sent is not recieved
before the timeout of the connection. If I set the timeout for example to
two seconds in the javascript initialization the message is received at the
end of the 2 second timeout. I was expecting the onsuccess to be called when
a message is received and the connection to reconnect but this is not the
case as I am experiencing.
I am testing the basic ActiveMQ AjaxServlet service to communicate with a
back end ActiveMQ service. The issue I am having is that the time it takes
to receive the message from the queue using the ajax client is sometimes 20+
seconds. The length of the delay is completely different every time but it
is long enough that I am concerned about going forward with the solution. I
have tried the prototype adapter and the jquery adapter and both exhibit the
same issues. I have tried multiple browsers and the same issues persists. I
have excellent connectivity with the remote queue and there is no delay
there.
**Edit**<br/>
I see that the message is being delayed 25 seconds which is the timeout of
the ajax connection. I don't think this is the correct behavior and it
should break when the message is received,then reconnect. Is this the
correct assumption?
ActiveMQ Version : 5.9.0 <br/>
Firefox: 28 <br/>
Chrome: Newest Release <br/>
Tomcat: 7.0.52
**web.xml**
<context-param>
<param-name>org.apache.activemq.brokerURL</param-name>
<param-value>tcp://remoteaddress.example:61616</param-value>
</context-param>
<servlet>
<servlet-name>AjaxServlet</servlet-name>
<servlet-class>org.apache.activemq.web.AjaxServlet</servlet-class>
<async-supported>true</async-supported>
</servlet>
<servlet>
<servlet-name>MessageServlet</servlet-name>
<servlet-class>org.apache.activemq.web.MessageServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<async-supported>true</async-supported>
</servlet>
<servlet-mapping>
<servlet-name>MessageServlet</servlet-name>
<url-pattern>/q/message/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>AjaxServlet</servlet-name>
<url-pattern>/q/ajax/*</url-pattern>
</servlet-mapping>
**Javascript**
--
View this message in context: http://activemq.2283324.n4.nabble.com/Lengthy-delays-when-using-ActiveMQ-Ajax-Client-tp4680130.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Lengthy delays when using ActiveMQ Ajax Client
Posted by Dejan Bosanac <de...@nighttale.net>.
It doesn't sound right. Any chance you can write a test case for that and
submit a Jira?
https://github.com/apache/activemq/blob/trunk/activemq-web-demo/src/test/java/org/apache/activemq/web/AjaxTest.java
Also, did you consider using WebSockets, as they are much better suit for
this in-browser kind of messaging that old Ajax servlet?
Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosanac@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Mon, Apr 7, 2014 at 11:25 PM, chinshaw <ch...@gmail.com> wrote:
> I posted this earlier on stackoverflow.com but this may be a better place
> to
> get some advice.
> I think my question simplified is should messages be received by the
> browser
> before the end of the timeout because if a message sent is not recieved
> before the timeout of the connection. If I set the timeout for example to
> two seconds in the javascript initialization the message is received at the
> end of the 2 second timeout. I was expecting the onsuccess to be called
> when
> a message is received and the connection to reconnect but this is not the
> case as I am experiencing.
>
>
>
> I am testing the basic ActiveMQ AjaxServlet service to communicate with a
> back end ActiveMQ service. The issue I am having is that the time it takes
> to receive the message from the queue using the ajax client is sometimes
> 20+
> seconds. The length of the delay is completely different every time but it
> is long enough that I am concerned about going forward with the solution. I
> have tried the prototype adapter and the jquery adapter and both exhibit
> the
> same issues. I have tried multiple browsers and the same issues persists. I
> have excellent connectivity with the remote queue and there is no delay
> there.
>
>
> **Edit**<br/>
>
> I see that the message is being delayed 25 seconds which is the timeout of
> the ajax connection. I don't think this is the correct behavior and it
> should break when the message is received,then reconnect. Is this the
> correct assumption?
>
>
>
>
> ActiveMQ Version : 5.9.0 <br/>
> Firefox: 28 <br/>
> Chrome: Newest Release <br/>
> Tomcat: 7.0.52
>
>
> **web.xml**
>
> <context-param>
> <param-name>org.apache.activemq.brokerURL</param-name>
>
> <param-value>tcp://remoteaddress.example:61616</param-value>
> </context-param>
>
> <servlet>
> <servlet-name>AjaxServlet</servlet-name>
>
> <servlet-class>org.apache.activemq.web.AjaxServlet</servlet-class>
> <async-supported>true</async-supported>
> </servlet>
>
> <servlet>
> <servlet-name>MessageServlet</servlet-name>
>
> <servlet-class>org.apache.activemq.web.MessageServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> <async-supported>true</async-supported>
> </servlet>
>
>
> <servlet-mapping>
> <servlet-name>MessageServlet</servlet-name>
> <url-pattern>/q/message/*</url-pattern>
> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>AjaxServlet</servlet-name>
> <url-pattern>/q/ajax/*</url-pattern>
> </servlet-mapping>
>
>
>
>
> **Javascript**
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Lengthy-delays-when-using-ActiveMQ-Ajax-Client-tp4680130.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>