Re: The future of Qpid Management.

On 02/23/2014 05:04 PM, Fraser Adams wrote: Obviously the Management Models of the C++ and Java Brokers have diverged somewhat over time as indeed have the capabilities of the two brokers [...] the divergent Management Models means that there is different *semantics* between the two Brokers

Re: Novice questions regarding dispatch routers and brokers +++

Dear Gordon, thanks for great and clarifying input! We have decided to do a PoC with the broker instead of the router to see how things work out. We'll post our findings (and questions ;) ) afterwards. When you say that there are plans to let the routers works alongside brokers, how would that

Re: Novice questions regarding dispatch routers and brokers +++

Remarks in-line below... -Ted On 02/25/2014 08:58 AM, Tor Rune Skoglund wrote: Dear Gordon, thanks for great and clarifying input! We have decided to do a PoC with the broker instead of the router to see how things work out. We'll post our findings (and questions ;) ) afterwards. When you

RE: JMS AMQP 1.0 - can the receiver.receive(timeout) return null even when timeout not expired?

Thanks Rob, From the log I read that the server sent End{} and this caused client to close the connection. Do I read it correctly? So it seems like Service Bus issue then. Kind regards, Jan [15:50:08] FINE: RECV[:5671|0] :

Re: JMS AMQP 1.0 - can the receiver.receive(timeout) return null even when timeout not expired?

Yes - it looks like servicebus send an unsolicited end... so that is the the place to investigate (unfortunately it doesn't seem like it provides any error information along with it). I notice that following that the client seems to send end twice which I should look into as that would be a bug -

Proton-j threading

Hello, In the java doc for Driver interface I see: Unless otherwise stated, methods on Driver implementations are not necessarily thread-safe. and during testing I got: Exception in thread Proton Reactor java.util.ConcurrentModificationException at

Re: Proton-j threading

To be honest I wouldn't necessarily bother using the Driver for proton-j. It is there to allow for testing, but it should be easy enough to either do your own I/O or use one of a number of off the shelf I/O libraries (getty, MINA, etc). All the driver does is provide a very simplistic way to pump

Re: The future of Qpid Management.

On 25/02/14 10:28, Gordon Sim wrote: [...] Similarly neither QMF nor AMQP 1.0 Management provide a way to introspect Method formal parameters. So you can get hold of the available Method names for sure, but arguments/parameters?? I think you can get this over QMF. For example, using

qpid 0.22 reconnect fails on centos 5

I have a two node cluster on a lan where I've installed qpid v 0.22. I have a centos 6 and a centos 5 client machine (not same machines as brokers) with same qpid version installed (built from source). The spout/drain test apps handle reconnects just fine on centos 6. On centos 5, messages are

Re: The future of Qpid Management.

On 25 February 2014 20:38, Fraser Adams fraser.ad...@blueyonder.co.ukwrote: On 25/02/14 10:28, Gordon Sim wrote: [...] Similarly neither QMF nor AMQP 1.0 Management provide a way to introspect Method formal parameters. So you can get hold of the available Method names for sure, but

Re: The future of Qpid Management.

I think the QMF and the tools around it demonstrate the problem of tools modeled only according to some schema. Utilities like qpid-tool allow you to find the schema details about the objects/classes and their methods and call these methods. But if you want to use the filter in the purge method of

Re: The future of Qpid Management.

On 25 February 2014 23:35, Jakub Scholz ja...@scholz.cz wrote: I think the QMF and the tools around it demonstrate the problem of tools modeled only according to some schema. Utilities like qpid-tool allow you to find the schema details about the objects/classes and their methods and call