On 14 February 2017 at 18:07, Benjamin Busjaeger <busjae...@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.
>> 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 <keith.w...@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 <rob.j.godf...@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 <rob.j.godf...@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 <keith.w...@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 <busjae...@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-unsubscr...@qpid.apache.org
>> >>> For additional commands, e-mail: users-h...@qpid.apache.org
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
