Re: C++ broker build not working: 'round' is not a member of 'std'

Hi Alan, Thanks for your help. The -std=c++11 flag indeed helps to work around the problem. Thanks & Regards Jakub On Mon, Feb 13, 2017 at 3:42 PM, Alan Conway wrote: > On Fri, 2017-02-10 at 22:46 +0100, Jakub Scholz wrote: > > Hi, > > > > I seem to be unable to build the

Re: [Dispatch Router] Unexpected behavior when starting the same dispatch router twice

Hello, Was anyone able to take a look at the submitted patches? Regards, Adel From: Adel Boutros Sent: Thursday, February 2, 2017 4:24:30 PM To: users@qpid.apache.org Subject: Re: [Dispatch Router] Unexpected behavior when starting the

Re: Qpid tools with python vs qpid-cpp messaging

On Mon, 2017-02-13 at 15:51 +, Gordon Sim wrote: > On 13/02/17 15:46, Chris Richardson wrote: > > Gordon mentioned switching between the qpid_messaging and > > qpid.messaging clients; I was slightly confused by this but hadn't > > got > > around to inquiring further - more specific details

Re: WebSocket timeout

On 14 February 2017 at 20:11, Robbie Gemmell wrote: > On 14 February 2017 at 18:07, Benjamin Busjaeger > wrote: > > Thanks for the replies! > > > >> I expect you are seeing the connection close after 300 seconds of > > inactivity > > That's right >

Re: [JMS]How to verify the connection is ready for creating session

On 02/14/2017 02:32 PM, pqvchen1 wrote: Just question further, is there a way that I can check whether the connection or session is healthy? and ready to send/receive message before I doing so? thanks again. Final question. You can send a message, and if it throws an exception then it's not

Re: [JMS]How to verify the connection is ready for creating session

Just question further, is there a way that I can check whether the connection or session is healthy? and ready to send/receive message before I doing so? thanks again. Final question. -- View this message in context:

Re: [JMS]How to verify the connection is ready for creating session

On 02/14/2017 02:12 PM, pqvchen1 wrote: Thanks for reply. So can I just keep that connection open and not close even after the session is done? and reuse the connection for next createSession? Yes, the Connection can remain open an be used to create multiple sessions either at once or many

Re: [JMS]How to verify the connection is ready for creating session

On 14 February 2017 at 19:12, pqvchen1 wrote: > Thanks for reply. So can I just keep that connection open and not close even > after the session is done? and reuse the connection for next createSession? > Yes, though better yet just don't close the session or

Re: [JMS]How to verify the connection is ready for creating session

Thanks for reply. So can I just keep that connection open and not close even after the session is done? and reuse the connection for next createSession? -- View this message in context:

Re: WebSocket timeout

On 14 February 2017 at 18:07, Benjamin Busjaeger 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

Re: [JMS]How to verify the connection is ready for creating session

On 14 February 2017 at 18:14, pqvchen1 wrote: > I'm using qpid-jms-client-0.11.1.jar and try to figure out how to verify if a > connection is ready for creating session. In initial I thought to check > whether the connection is null or not and then realized that the

Re: [JMS] can I include ssl keystore & truststore in connectionfactory string

On 14 February 2017 at 18:05, pqvchen1 wrote: > I'm using qpid-jms-client-0.11.1 and just wonder if there is a way to include > all the keystore & truststore information in connection URL? > > Here is a sample of my connection URL: > Hashtable env = new

[JMS]How to verify the connection is ready for creating session

I'm using qpid-jms-client-0.11.1.jar and try to figure out how to verify if a connection is ready for creating session. In initial I thought to check whether the connection is null or not and then realized that the connection object could be not null even it is not healthy to create a new

Re: WebSocket timeout

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*

Test framework for testing AMQP

Hi all, The Qpid Java Broker team came to the realization that we have a gap in our system tests for Qpid Java Broker. At the moment our system tests are based on API provided by JMS client implementations. The JMS API does not allow us to test all aspects of AMQP implementation on broker side.