-
1. Re: Receiving XML from c++ sender
clebert.suconic Jul 29, 2009 12:31 PM (in response to sanches)You better asking that to ActiveMQ guys :-)
-
2. Re: Receiving XML from c++ sender
sanches Jul 29, 2009 12:49 PM (in response to sanches)Heh,
any glue to what I can tell them about JBoss Messaging?
Like specific internal format of JMS protocol inplemented in JBM? -
3. Re: Receiving XML from c++ sender
clebert.suconic Jul 29, 2009 12:59 PM (in response to sanches)Is it possible to receive TextMessages (with XML payload) from the client written in c++ and using ActiveMQ? What URI should be given to the cpp client in such a case?
Sorry... your question was a little bit obscure to me...
I couldn' t realize you wanted to transfer messages from ActiveMQ to JBossMessaging.
We are scheduled to implement AMQP on JBoss Messaging 2, what will enabled C++ to connect to JBoss Messaging.
You will be able to configure the bridge between ActiveMQ and JbossMessaging.
While we don' t have a C++ client to connect to JBoss Messaging, you could use RedHat Messaging.
RedHat messaging is the C++ side of the project.
http://jboss.org/rhmessaging/ -
4. Re: Receiving XML from c++ sender
sanches Jul 29, 2009 1:24 PM (in response to sanches)I am afraid that important links on the page you gave link to are broken...
Downloads & Getting Started
http://rhm.et.redhat.com/page/Getting_Started_With_RHM
Red Hat Messaging Technology Preview 0.1
http://jboss.org/downloading/?projectId=rhmessaging&url=http://rhm.et.redhat.com/page/Getting_Started_With_RHM#Download_Red_Hat_Messaging
Is opensource Redhat messaging still supported actively? -
5. Re: Receiving XML from c++ sender
bryanche Jul 30, 2009 9:37 AM (in response to sanches)Those links are deprecated. You should take a look at http://www.redhat.com/mrg/messaging/ and http://www.redhat.com/mrg/. Red Hat Enterprise MRG Messaging includes a C++ client (as well as JMS, Python, .Net, etc) and implements AMQP.
-
6. Re: Receiving XML from c++ sender
sanches Jul 30, 2009 9:55 AM (in response to sanches)Red Hat Enterprise MRG http://www.redhat.com/mrg/buy looks like a proprietary commercial solution. Isn't it?
-
7. Re: Receiving XML from c++ sender
bryanche Jul 30, 2009 12:16 PM (in response to sanches)MRG is a 100% open source product that we sell subscriptions around. It's built from a wide variety of open source projects and not one single project. If you'd like to understand how that works and how to get at the various projects, send me an e-mail and I'll follow up with you. bche at redhat dot com.
-
8. Re: Receiving XML from c++ sender
jonathan.robie Jul 31, 2009 8:58 AM (in response to sanches)"clebert.suconic@jboss.com" wrote:
RedHat messaging is the C++ side of the project.
http://jboss.org/rhmessaging/
Sorry for the confusion - that was an old page, which now redirects to the current project page at QpidComponents.org.
The Apache Qpid broker itself is developed at qpid.apache.org. Persistence and management tools that can not be developed using the Apache license are developed at QpidComponents.org (these are still open source). The Red Hat commercial offering is at http://redhat.com/mrg/messaging.
Hope this clarifies!
Jonathan -
9. Re: Receiving XML from c++ sender
clebert.suconic Jul 31, 2009 9:26 AM (in response to sanches)... and JBossMessaging will implement AMQP, and other clients such as C++, .NET will be able to connect to JBoss Messaging 2 using those libraries, which is a nice synergy.
-
10. Re: Receiving XML from c++ sender
timfox Aug 1, 2009 3:23 AM (in response to sanches)"sanches" wrote:
Hello all,
Is it possible to receive TextMessages (with XML payload) from the client written in c++ and using ActiveMQ?
What URI should be given to the cpp client in such a case?
Thanks.
Yes, it's possible to use activemq with c++ clients, but I don't see how that is related to JBoss Messaging. Look at the activemq docs and website for more info. -
11. Re: Receiving XML from c++ sender
timfox Aug 1, 2009 3:26 AM (in response to sanches)"clebert.suconic@jboss.com" wrote:
Is it possible to receive TextMessages (with XML payload) from the client written in c++ and using ActiveMQ? What URI should be given to the cpp client in such a case?
Sorry... your question was a little bit obscure to me...
I couldn' t realize you wanted to transfer messages from ActiveMQ to JBossMessaging.
You can use a JMS bridge to do this *already* in JBM 1.x and 2.x.
We are scheduled to implement AMQP on JBoss Messaging 2, what will enabled C++ to connect to JBoss Messaging.
You can already use a Stomp client to talk to JBoss Messaging 1.x/2.x using StompConnect (google it) -
12. Re: Receiving XML from c++ sender
timfox Aug 1, 2009 3:29 AM (in response to sanches)"clebert.suconic@jboss.com" wrote:
... and JBossMessaging will implement AMQP, and other clients such as C++, .NET will be able to connect to JBoss Messaging 2 using those libraries, which is a nice synergy.
Not only AMQP, JBM will be implementing REST and STOMP natively giving you a very large range of options for messaging interoperability. -
13. Re: Receiving XML from c++ sender
sanches Aug 1, 2009 3:51 AM (in response to sanches)
You can use a JMS bridge to do this *already* in JBM 1.x and 2.x.
Could you tell a little bit more about JMS bridge please?
On which configuration it could be applied?
Aim is to retrieve messages from C++ client on JBoss side. -
14. Re: Receiving XML from c++ sender
sanches Aug 1, 2009 4:04 AM (in response to sanches)"timfox" wrote:
You can already use a Stomp client to talk to JBoss Messaging 1.x/2.x using StompConnect (google it)
Thanks, I am already paying attention to StompConnect.
I've faced an issue which I can not resolve with StompConnect however:
Configuration is:
- C++ client (ActiveMQ CMS over Stomp) is sender
- JBoss 5.0 with MQ (not JBoss Messaging, sorry, I used default on JBoss 5.0) and MDB is receiver. StompConnect's thread is working inside JBoss
When the name of the JMS topic is laconic "SERVER", c++ client sends message to topic "SERVER", and MDB listening for messages from topic "SERVER", everything is transmitted well.
But when the name of the JMS topic is "SERVER/TOP" (there is slash in the name), c++ client sends message to topic "SERVER/TOP", and MDB listening for messages from topic "SERVER/TOP", an exception is thrown on JBoss side. Full stack of exception is at the end of this message.
However, at the same time when the name of the JMS topic is "SERVER/TOP", but c++ client sends message to topic "SERVER", and MDB still listening for messages from topic "SERVER/TOP", message is received properly. That case is detected accidentally.
Once again in two words, MDB on JBoss can not receive message if it has been sent by cpp client to destination which contains slashes. By some reason in such case message is routed into topic which name is substring before slash.
Alex.
Exception:
11:42:21,562 ERROR [ExceptionUtil] SessionEndpoint[7b-y2923txf-1-zooy2txf-2p9g2a-w30b3a] createTopic [8b-y2923txf-1-zooy2txf-2p9g2a-w30b3a]
javax.jms.JMSException: There is no administratively defined topic with name:SERVER/TOP
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createTopic(ServerSessionEndpoint.java:321)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$createTopic$aop(SessionAdvised.java:110)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$createTopic_N1144803973659535745.invokeTarget(SessionAdvised$createTopic_N1144803973659535745.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.createTopic(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionCreateTopicRequest.serverInvoke(SessionCreateTopicRequest.java:74)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1708)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.remoting.Client.invoke(Client.java:600)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$createTopic$aop(ClientSessionDelegate.java:353)
at org.jboss.jms.client.delegate.ClientSessionDelegate$createTopic_N1144803973659535745.invokeTarget(ClientSessionDelegate$createTopic_N1144803973659535745.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientSessionDelegate.createTopic(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.createTopic(JBossSession.java:260)
at org.codehaus.stomp.jms.StompSession.convertDestination(StompSession.java:96)
at org.codehaus.stomp.jms.StompSession.sendToJms(StompSession.java:71)
at org.codehaus.stomp.jms.ProtocolConverter.onStompSend(ProtocolConverter.java:260)
at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:132)
at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:131)
at java.lang.Thread.run(Thread.java:619)