Re: WebSocket timeout

[Benjamin Busjaeger <bu...@gmail.com>]

Thanks, setting amqp.idleTimeout=0 works.

On Tue, Feb 14, 2017 at 12:04 PM Rob Godfrey <ro...@gmail.com>
wrote:

> On 14 February 2017 at 20:11, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > On 14 February 2017 at 18:07, Benjamin Busjaeger <bu...@gmail.com>
> > wrote:
> > > Thanks for the replies!
> > >
> > >> I expect you are seeing the connection close after 300 seconds of
> > > inactivity
> > > That's right
> > >
> > >> I've raised https://issues.apache.org/jira/browse/QPID-7670 to cover
> > this
> > > issue
> > > Thank you
> > >
> > >> to workaround this issue in v6.1 of the broker all you need to do is
> get
> > > the *broker* to request the *client* to send "heartbeat" messages
> > > Thanks, that workaround unblocks me.
> > >
> > >> you'd also have to remove the "&amqp.idleTimeout=3600000"
> > > If I remove the that parameter, the simple client program times out
> after
> > > 90 seconds:
> > >
> > > javax.jms.JMSException: Transport closed due to the peer exceeding our
> > > requested idle-timeout
> > > [...]
> > > Caused by: java.io.IOException: Transport closed due to the peer
> > exceeding
> > > our requested idle-timeout
> > >
> > > If I set the idleTimeout to 100 seconds (in addition to the broker
> > > heartBeatDelay=60 parameter), the client completes successfully. Is
> that
> > > expected behavior?
> > >
> >
> > The client defaults to having a 60sec timeout so if the broker isnt
> > sending it heartbeats or other data regularly enough it will time out.
> > To disable the client requesting heartbeats and enforcing the server
> > idle period, try setting its config to 0 instead of removing it.
> >
> >
> Apologies - that was my fault - I should have read the docs :-)
>
> -- Rob
>
>
> > >> We plan to include this in Qpid Broker for Java 6.1.2.
> > > Thank you
> > >
> > > On Mon, Feb 13, 2017 at 3:23 AM Keith W <ke...@gmail.com> wrote:
> > >
> > >> We plan to include this in Qpid Broker for Java 6.1.2.
> > >>
> > >> On 13 February 2017 at 11:04, Rob Godfrey <ro...@gmail.com>
> > wrote:
> > >> > As a colleague (thanks Robbie!) also pointed out to me, to
> workaround
> > >> this
> > >> > issue in v6.1 of the broker all you need to do is get the *broker*
> to
> > >> > request the *client* to send "heartbeat" messages more frequently
> than
> > >> the
> > >> > Jetty timeout.  You can do this by adding your config.json to add a
> > >> setting
> > >> > for "connection.heartBeatDelay", setting it to 60 seconds for
> example:
> > >> >
> > >> > After such a change, my config.json start like this:
> > >> >
> > >> > {
> > >> >   "id" : "91fedfad-7c78-4b1e-b78c-70be39433bea",
> > >> >   "name" : "${broker.name}",
> > >> >   "modelVersion" : "6.1",
> > >> >   "connection.heartBeatDelay" : 60,
> > >> >   "authenticationproviders" : [ {
> > >> >
> > >> >  ...
> > >> >
> > >> >
> > >> > Since the broker for 6.1 doesn't respect client requested
> heartbeating
> > >> > (until we fix that bug), you'd also have to remove the
> > >> > "&amqp.idleTimeout=3600000" from you client connection URL...
> however
> > >> > hopefully this is enough to get you going for the moment.
> > >> >
> > >> > Apologies you ran into this defect - we'll try to release a new
> > version
> > >> > including the fix as soon as possible.
> > >> >
> > >> > Hope this helps,
> > >> > Rob
> > >> >
> > >> > On 13 February 2017 at 11:15, Rob Godfrey <ro...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> I've raised https://issues.apache.org/jira/browse/QPID-7670 to
> cover
> > >> this
> > >> >> issue, and made a change on trunk which I believe will provide the
> > >> expected
> > >> >> behaviour wrt AMQP idle timeouts.
> > >> >>
> > >> >> -- Rob
> > >> >>
> > >> >> On 13 February 2017 at 00:04, Keith W <ke...@gmail.com>
> wrote:
> > >> >>>
> > >> >>> Hi Benjamin,
> > >> >>>
> > >> >>> This is a defect in the Qpid Broker for Java.  After running your
> > >> >>> code, I expect you are seeing the connection close after 300
> seconds
> > >> >>> of inactivity.  This will be Jetty's
> > >> >>> org.eclipse.jetty.websocket.WebSocketFactory#maxIdleTime default,
> > >> >>> which is forcing the idle connection to close.  The Broker
> currently
> > >> >>> provides no way to override this value.  To workaround you'd need
> to
> > >> >>> find a way to keep the wire busy from the application (perhaps
> > sending
> > >> >>> an empty message, with a TTL, to a 'heartbeat' queue).
> > >> >>>
> > >> >>> The Broker ought to be respecting the peer's requested idle
> timeout
> > >> >>> for websocket connections and ensuring that Jetty's maxIdleTime
> does
> > >> >>> not interfere.  This currently is not implemented.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> > transport-v1.0-os.html#doc-doc-idle-time-out
> > >> >>>
> > >> >>> Please raise a JIRA https://issues.apache.org/jira/browse/QPID.
> > There
> > >> >>> is a defect fix release due on 6.1 soon, so it may be possible to
> > >> >>> include this too.   Patches are always appreciated too.
> > >> >>>
> > >> >>> Kind regards, Keith.
> > >> >>>
> > >> >>>
> > >> >>> On 11 February 2017 at 16:37, Benjamin Busjaeger <
> > busjaeger@gmail.com>
> > >> >>> wrote:
> > >> >>> > Is there a way to keep JMS WebSocket connections open (e.g.,
> > enable
> > >> >>> > ping/pong heartbeats)?
> > >> >>> >
> > >> >>> > I get the following error:
> > >> >>> >
> > >> >>> > javax.jms.JMSException: Transport connection remotely closed.
> > >> >>> >
> > >> >>> > at org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(
> > >> >>> > JmsExceptionSupport.java:86)
> > >> >>> >
> > >> >>> > at org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(
> > >> >>> > JmsExceptionSupport.java:108)
> > >> >>> >
> > >> >>> > at org.apache.qpid.jms.JmsConnection.onAsyncException(
> > >> >>> > JmsConnection.java:1385)
> > >> >>> >
> > >> >>> > at org.apache.qpid.jms.JmsConnection.onProviderException(
> > >> >>> > JmsConnection.java:1369)
> > >> >>> >
> > >> >>> > at org.apache.qpid.jms.JmsConnection.onConnectionFailure(
> > >> >>> > JmsConnection.java:1237)
> > >> >>> >
> > >> >>> > at
> > >> >>> > org.apache.qpid.jms.provider.amqp.AmqpProvider.
> > fireProviderException(
> > >> >>> > AmqpProvider.java:1015)
> > >> >>> >
> > >> >>> > at org.apache.qpid.jms.provider.amqp.AmqpProvider$20.run(
> > >> >>> > AmqpProvider.java:830)
> > >> >>> >
> > >> >>> > at
> > >> >>> >
> > >>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> > >> >>> >
> > >> >>> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > >> >>> >
> > >> >>> > at
> > >> >>> >
> > >> >>> >
> > >> java.util.concurrent.ScheduledThreadPoolExecutor$
> > ScheduledFutureTask.access$201(
> > >> >>> > ScheduledThreadPoolExecutor.java:180)
> > >> >>> >
> > >> >>> > at
> > >> >>> >
> > >> java.util.concurrent.ScheduledThreadPoolExecutor$
> > ScheduledFutureTask.run(
> > >> >>> > ScheduledThreadPoolExecutor.java:293)
> > >> >>> >
> > >> >>> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > >> >>> > ThreadPoolExecutor.java:1142)
> > >> >>> >
> > >> >>> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > >> >>> > ThreadPoolExecutor.java:617)
> > >> >>> >
> > >> >>> > at java.lang.Thread.run(Thread.java:745)
> > >> >>> >
> > >> >>> > Caused by: java.io.IOException: Transport connection remotely
> > closed.
> > >> >>> >
> > >> >>> > ... 8 more
> > >> >>> >
> > >> >>> > With a relatively simple client program:
> > >> >>> >
> > >> >>> >             Context context = new InitialContext();
> > >> >>> >
> > >> >>> >
> > >> >>> >             ConnectionFactory factory = (ConnectionFactory)
> > >> >>> > context.lookup(
> > >> >>> > "myFactoryLookup");
> > >> >>> >
> > >> >>> >             Destination queue = (Destination)
> > >> >>> > context.lookup("myQueueLookup"
> > >> >>> > );
> > >> >>> >
> > >> >>> >
> > >> >>> >             Connection connection = factory.createConnection("
> > admin",
> > >> >>> > "admin");
> > >> >>> >
> > >> >>> >             connection.setExceptionListener(new
> > >> MyExceptionListener());
> > >> >>> >
> > >> >>> > //            connection.start();
> > >> >>> >
> > >> >>> >
> > >> >>> >             Session session = connection.createSession(false,
> > >> Session.
> > >> >>> > AUTO_ACKNOWLEDGE);
> > >> >>> >
> > >> >>> >             session.createProducer(queue);
> > >> >>> >
> > >> >>> >             Thread.sleep(360000);
> > >> >>> >
> > >> >>> > jndi properties:
> > >> >>> >
> > >> >>> > java.naming.factory.initial =
> > >> >>> > org.apache.qpid.jms.jndi.JmsInitialContextFactory
> > >> >>> >
> > >> >>> > connectionfactory.myFactoryLookup = amqpws://localhost
> > >> >>> > :5000?amqp.vhost=default&amqp.idleTimeout=3600000
> > >> >>> >
> > >> >>> > queue.myQueueLookup = Q1
> > >> >>> >
> > >> >>> > Server version: qpid - 6.1.1 build: 1775107 (AMQP version(s)
> > >> >>> > [major.minor]:
> > >> >>> > 0-8, 0-9, 0-9-1, 0-10, 1.0)
> > >> >>> > Client version: qpid-jms-client-0.20.0 with proton-j-0.16.0
> > >> >>> >
> > >> >>> > Thanks,
> > >> >>> > Ben
> > >> >>>
> > >> >>> ------------------------------------------------------------
> > ---------
> > >> >>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> >>> For additional commands, e-mail: users-help@qpid.apache.org
> > >> >>>
> > >> >>
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: users-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>