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 <[email protected]> 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 <[email protected]> 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-trans
>> port-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 <[email protected]>
>> 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.fireProviderE
>> xception(
>> > 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$ScheduledFu
>> tureTask.access$201(
>> > ScheduledThreadPoolExecutor.java:180)
>> >
>> > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> tureTask.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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
