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.redh...@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! >
