On Wed, 2010-08-18 at 09:16 -0700, cppdeveloper wrote: > Failover is crucial, so I will have to use my backup method, which is > converting the broker cluster from OpenMQ to ActiveMQ 5, but it still needs > to work in Glassfish V2. > > FYI I have done some pretty thorough research on OpenMQ and > ActiveMQ/ActiveMQ-CPP about STOMP and failover and I never saw it written > anywhere that both would not be supported simultaneously. It would probably > be a good idea to write that somewhere so people don't spend days trying to > configure something that will never work anyways.
I updated the Wiki to reflect the advice not to combine Stomp and Failover. Stomp is a pretty basic protocol and as such there are limits to what can be done with it, you could implement some basic failover using the current v1.0 spec in ActiveMQ-CPP but it would have its limits. Until the v1.1 Stomp spec is ratified its hard to detect in most cases that the tcp connection has been broken as there are no KeepAlive messages between broker and client. > > Thanks for the heads up. > > > Timothy Bish wrote: > > > > On Wed, 2010-08-18 at 08:35 -0700, cppdeveloper wrote: > >> > >> > >> Timothy Bish wrote: > >> > > >> > Can you add some code to dump the contents of the Response frame sent > >> > from OpenMQ? This would help me understand why its not being > >> > processed. > >> > > >> > >> According to an OpenMQ developer, he thought the problem may be this: > >> > >> "IIRC the Stomp frames in OpenMQ always use a content-length header while > >> ActiveMQ uses this header for binary messages only, and uses a null byte > >> terminator for text messages. > >> So I think that the ActiveMQ Stomp library times out because if waits for > >> the null byte, which never is sent from the OpenMQ broker. > >> Hope this helps, > >> Michael" > >> > >> Other than adjusting the output from the OpenMQ broker, is there any way > >> to > >> change how the ActiveMQ-CPP client handles this? > > > > Since its hanging during the Connect phase then the content-length > > property wouldn't come into play here since you aren't at the point of > > even sending or receive Stomp Send / Message Frames, the exchange at > > this point would either be the Connect / Connected exchange or a > > Subscribe if you are getting to the point of actually creating a > > Consumer. > > > > The content-length is optional in Stomp 1.0 for Send / Message frames > > and the frame must end in a newline either way so in that regards AMQCPP > > is stomp compliant. > > > >> > >> > >> Timothy Bish wrote: > >> > > >> > Can I ask why you need to use ActiveMQ-CPP to talk stomp to OpenMQ, > >> > don't they have a C client for OpenMQ? > >> > > >> > >> We already have an exisitng broker cluster of OpenMQ brokers, and we need > >> a > >> C++ client to interact with them, but we also need it to use failover, > >> which > >> their C client does not. Thus far, ActiveMQ-CPP has seemed like the best > >> open source option, if they could connect/communicate correctly! > >> > > > > You won't be able to use the Failover Transport with the Stomp transport > > as Stomp doesn't support a reliability mechanism for connection > > monitoring nor does it allow for subscription recovery so the Failover > > support in AMQCPP isn't going to work when you are connected to Stomp. > > > > > > Regards > > > > > > -- > > Tim Bish > > > > Open Source Integration: http://fusesource.com > > ActiveMQ in Action: http://www.manning.com/snyder/ > > > > Follow me on Twitter: http://twitter.com/tabish121 > > My Blog: http://timbish.blogspot.com/ > > > > > > >
