activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <mtay...@redhat.com>
Subject Re: Problems using Qpid Proton-J with Artemis Core
Date Tue, 09 Aug 2016 11:31:54 GMT
Hi Andy,

The attachments don't seem to have come through for me?  Could you please
send over the broker.xml and your log out put and I will take a look.

I noticed you referred to the docs from 1.0.0, we're up to 1.3.0 now I
would use the latest version of the broker and docs.

Thanks
Martyn


On Tue, Aug 9, 2016 at 11:36 AM, Andy Redhead <andy.redhead@oneadvanced.com>
wrote:

> Hi,
>
> I'm new to Artemis and AMQP so it's quite likely I'm doing something
> stupid...
>
> I'd like to be able to send messages from an AMQP client through Artemis
> to a Java client (running in the same JVM as Artemis, using an in-VM
> connector).
>
> For now, the remote client is written in Java using the Apache Qpid
> Proton-J AMQP library. Longer term, the client will be written in C.
>
> The code is running on my macbook pro laptop using Oracle Java8 (no native
> libraries installed).
>
> The problem I have is that when I try to use Proton-J to send (or receive)
> messages via Artemis, no messages are sent/received and the interaction
> between the clients and Artemis server look a bit "strange" (more below).
>
> I'd really appreciate some pointers on how to get (Java) AMQP clients
> interacting with Artemis.
>
> (the Artemis documentation at: https://activemq.apache.org/
> artemis/docs/1.0.0/examples.html talks about an example in the section
> titled "Proton Qpid" that refers to an example called "proton-j" - this
> doesn't seem to exist in the distribution or on GitHub, there is an example
> called "Queue" that uses Qpid JMS but I'm not sure that's relevant as I
> don't want to use JMS and I want to use a queue that already exists in
> Artemis, rather than creating a new queue when the producer connects)
>
> The rest of this email describes what I've been doing...
>
> The server side is a an embedded Artemis core that is started up by a
> simple spring app running in Tomcat (spring config and source code
> "AsyncMsgBrokerAmqArtemis.java" attached).
>
> The broker.xml file used to configure Artemis is also attached. It is
> intentionally a very minimal configuration, with no security or message
> persistence. There are acceptors configured for both the default Artemis
> port and the default AMQP port.
>
> I think this setup works because if I use a remote client using the core
> Artemis API I can send and receive messages as expected.
>
> Now to the behaviour using AMQP...
>
> Code for the producer (QpidProtonSend.java) and consumer
> (QpidProtonReceive.java) is attached, both classes are pretty much the qpid
> example code available at:
>
> https://github.com/apache/qpid-proton/blob/master/
> examples/java/messenger/src/main/java/org/apache/qpid/proton/example
>
> There is a queue called "ctest" in broker.xml, I'm intending for the
> producer to write messages onto that queue and the consumer to read
> messages from that queue.
>
>
> Producer)
>
> I start the producer from a command line using a command such as:
>
> java -classpath './build/output/lib/*:./build/libs/*'
> com.adv365.solutions.asyncmsg.amqpclient.QpidProtonSend -a
> amqp://localhost:5672/ hello
>
> When the client is first started the producer writes the following to
> stdout:
>
> put message: Message{properties=Properties{messageId=null, userId=null,
> to='amqp://localhost:5672/', subject='null', replyTo='null',
> correlationId=null, contentType=null, contentEncoding=null,
> absoluteExpiryTime=null, creationTime=null, groupId='null',
> groupSequence=null, replyToGroupId='null'}body=AmqpValue{hello}}
>
> Then things seem to hang for about a minute until finally (probably linked
> to a timeout at the server end, see server trace level logs
> "server-send-log.txt") the producer writes the following to stdout:
>
> sent message: Message{properties=Properties{messageId=null, userId=null,
> to='amqp://localhost:5672/', subject='null', replyTo='null',
> correlationId=null, contentType=null, contentEncoding=null,
> absoluteExpiryTime=null, creationTime=null, groupId='null',
> groupSequence=null, replyToGroupId='null'}body=AmqpValue{hello}}
>
> In the server logs there is a line for when the producer connects:
>
> 2016-08-09T10:33:29,985 4900511 [Thread-11 (activemq-netty-threads-1155186594)]
> TRACE o.a.a.a.c.r.s.i.RemotingServiceImpl - Connection created
> org.apache.activemq.artemis.core.remoting.impl.netty.
> NettyServerConnection@4b2fd1ac[local= /127.0.0.1:5672, remote=/
> 127.0.0.1:52719]
>
> And around a minute later, visibly around the same time as the producer
> claims to have sent a message there is the line:
>
> 2016-08-09T10:34:31,353 4961879 [activemq-failure-check-thread] DEBUG
> o.a.a.a.c.r.s.i.RemotingServiceImpl - RemotingServiceImpl::removing
> connection ID -1728467180
>
> The following log lines are available in full in server-send-log.txt, I
> think the key point is:
>
>        "Did not receive data from /127.0.0.1:52719"
>
> My two observations about this are:
>  - why did the producer hang until something timed out on the server,
> rather than simply sending a message and disconnecting immediately?
>  - why does the producer think that a message has been sent ok while the
> server doesn't think it received any data?
>
>
> Consumer)
>
> With a freshly re-started tomcat, I start the consumer in a new command
> prompt using:
>
> java -classpath './build/output/lib/*:./build/libs/*'
> com.adv365.solutions.asyncmsg.amqpclient.QpidProtonReceive -a
> amqp://localhost:5672/ctest
>
> The consumer writes to stdout:
>
> Qpid receiver subscribed to address: amqp://localhost:5672/ctest
>
> The consumer then hangs for about a minute (until something times out on
> the server side) and then starts printing:
>
> Qpid receiver before while, incoming count: 0
>
> (I put a Thread.pause(2000) in the while loop that reads messages in as
> without it went into a tight loop)
>
> On the server side the logs show a similar pattern to the producer case
> (full text in attachment "server-receive-log.txt"), starting with a
> connection being made:
>
> 2016-08-09T11:05:24,456 276082 [Thread-3 (activemq-netty-threads-281722346)]
> TRACE o.a.a.a.c.r.s.i.RemotingServiceImpl - Connection created
> org.apache.activemq.artemis.core.remoting.impl.netty.
> NettyServerConnection@4c2adf51[local= /127.0.0.1:5672, remote=/
> 127.0.0.1:53034]
>
> Then around a minute later the server kills off the connection:
>
> 2016-08-09T11:06:24,711 336337 [activemq-failure-check-thread] DEBUG
> o.a.a.a.c.r.s.i.RemotingServiceImpl - RemotingServiceImpl::removing
> connection ID -2079259663
>
> My observations on this are:
>  - Why did the consumer hang until the server side timed out
>  - Once the server had timed out, why did the client start to poll as if
> nothing was wrong?
>
> Cheers, Andy
>
> Andy Redhead
> Principal Consultant > Solutions > Advanced ________________________
>
> Advanced
> 230 City Road, London, EC1V 2TT
> t: 020 7880 8888 > m: 0781 392 5246
>
> www.oneadvanced.com
>
> > A Sunday Times Top Track 250 Company 2015
> > Ranked in UK's 50 fastest growing technology companies 2014
>
> ***** Email confidentiality *****
>
> This message is private and confidential. If you have received this
> message in error, please notify us and remove it from your system. The
> dissemination, copying or distribution of this message, or related files,
> by anyone other than the intended recipient is strictly prohibited.
>
>
>
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Advanced 365 Limited.
>
>
>
> ***** Email monitoring *****
>
> Advanced 365 Limited may monitor email traffic data and also the content
> of email for the purposes of security and staff training.
>
>
>
> ***** Email security *****
>
> In keeping with good computing practice, the recipient of this email
> should ensure that it is virus-free. Advanced 365 Limited does not accept
> responsibility for any virus that may be transferred by way of this email.
>
>
>
> Email may be susceptible to data corruption, interception and/or
> unauthorised amendment. Advanced 365 Limited does not accept liability for
> any such corruption, interception or amendment or any consequences thereof.
>
>
>
> This email has been scanned for viruses by the Symantec Email
> Security.cloud service.
>
>
>
> Advanced 365 Limited, part of the Advanced Computer Software Group
>
> Registered office: Ditton Park, Riding Court Road, Datchet, Berkshire, SL3
> 9LL, UK
>
> Registered in England under number 2124540
>
> ________________________________
>
> Please consider the environment: Think before you print!
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message