We plan to include this in Qpid Broker for Java 6.1.2. On 13 February 2017 at 11:04, Rob Godfrey <[email protected]> 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 <[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-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 <[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.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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
