Re: Several issues with the Java Broker

2016-01-20 Thread Rob Godfrey
On 20 January 2016 at 13:33, Gordon Sim wrote: > On 01/20/2016 12:53 PM, Rob Godfrey wrote: > >> There is no single point where "it is fully configured for use" in the >> case >> of HA a virtual host may transition from a REPLICA state to a MASTER state >> (or vice versa) at any time, >> > > In t

Re: Several issues with the Java Broker

2016-01-20 Thread Gordon Sim
On 01/20/2016 12:53 PM, Rob Godfrey wrote: There is no single point where "it is fully configured for use" in the case of HA a virtual host may transition from a REPLICA state to a MASTER state (or vice versa) at any time, In the case of transferring from MASTER to REPLICA, simply dropping the

Re: Several issues with the Java Broker

2016-01-20 Thread Rob Godfrey
On 20 January 2016 at 12:11, Gordon Sim wrote: > On 01/20/2016 10:48 AM, Rob Godfrey wrote: > >> What I get from this is that the C++ client gives up retrying when it gets >> a 320 (connection forced) reply from the broker. >> > > Indeed, the retry gives up when it gets an explicit close rather t

Re: Several issues with the Java Broker

2016-01-20 Thread Gordon Sim
On 01/20/2016 10:48 AM, Rob Godfrey wrote: What I get from this is that the C++ client gives up retrying when it gets a 320 (connection forced) reply from the broker. Indeed, the retry gives up when it gets an explicit close rather than the socket failing. As Keith mentioned earlier, the er

Re: Several issues with the Java Broker

2016-01-20 Thread Rob Godfrey
On 18 January 2016 at 22:59, Keith W wrote: > Hello > > On 17 January 2016 at 18:34, rat...@web.de wrote: > > << snip >> > > > 2.) Message user-Id > > Using the java broker, the client seems to be able to set any user id. > > However, the broker does not seem to reject messages with wrong user

Re: Several issues with the Java Broker

2016-01-20 Thread Rob Godfrey
What I get from this is that the C++ client gives up retrying when it gets a 320 (connection forced) reply from the broker. As Keith mentioned earlier, the error message is basically saying "Yes, the broker is up... but it isn't fully configured yet", and the 320 error code (as defined by the AMQP

Re: Several issues with the Java Broker

2016-01-20 Thread rat...@web.de
Ok, I was able to produce a protocol trace with trace+ The situation is as follows: First the client is started. The broker is not active and thus the client is trying to reconnect. Then, after a while, I start the broker. When the broker is almost booted completely, the client receives the corresp

Re: Several issues with the Java Broker

2016-01-19 Thread Gordon Sim
On 01/19/2016 06:29 PM, rat...@web.de wrote: I can't generate a protocol trace with the c++ api run your program with QPID_LOG_ENABLE=trace+ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands,

Re: Several issues with the Java Broker

2016-01-19 Thread rat...@web.de
Thx for the answer. Im using the newest qpid messaging api (c++), v0.34 together with the newest Java broker (6.0.0). The protocol is AMQP 0-10. I'm afraid that I can't generate a protocol trace with the c++ api, right? But indeed the startup phase of the broker seems to be the problem. If it's not

Re: Several issues with the Java Broker

2016-01-18 Thread Keith W
Hello On 17 January 2016 at 18:34, rat...@web.de wrote: > Hi, > I'm having several problems with the Java broker: > > 1.) Reconnect functionality: > If I specify the reconnect:True option for my connection, the client tries > to reconnect to the broker if the connection is lost (which is correct)