You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Andy Redhead <an...@oneadvanced.com> on 2016/08/09 10:36:04 UTC

Problems using Qpid Proton-J with Artemis Core

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!

RE: Problems using Qpid Proton-J with Artemis Core

Posted by Andy Redhead <an...@oneadvanced.com>.
Hi,

In an attempt to answer my own question, it seems that I was missing the dependency:

compile group: 'org.apache.activemq', name: 'artemis-amqp-protocol', version: '1.3.0'

With that included in my build, when the server starts I now see the line:

Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP

With that in place, the producer now seems to do the put and send straight after each other and exit as expected, however the consumer still doesn't receive the message. The server logs show:

2016-08-09T13:28:11,699 319102 [Thread-4 (activemq-netty-threads-746685035)] TRACE o.a.a.a.c.r.s.i.RemotingServiceImpl - Connection created org.apache.activemq.artemis.core.remoting.impl.netty.NettyServerConnection@3388817[local= /127.0.0.1:5672, remote=/127.0.0.1:55306]
2016-08-09T13:28:11,717 319120 [Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@19854ceb-1194181639)] TRACE o.a.a.a.c.t.impl.TransactionImpl - TransactionImpl::rollback::TransactionImpl [xid=null, id=7, xid=null, state=ACTIVE, createTime=1470745691717(Tue Aug 09 13:28:11 BST 2016), timeoutSeconds=300, nr operations = 0]@4e1d1cc8
2016-08-09T13:28:11,718 319121 [Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@19854ceb-1194181639)] TRACE o.a.a.a.c.t.impl.TransactionImpl - TransactionImpl::internalRollback TransactionImpl [xid=null, id=7, xid=null, state=ACTIVE, createTime=1470745691717(Tue Aug 09 13:28:11 BST 2016), timeoutSeconds=300, nr operations = 0]@4e1d1cc8
2016-08-09T13:28:11,719 319122 [Thread-4 (activemq-netty-threads-746685035)] TRACE o.a.a.a.c.r.s.i.RemotingServiceImpl - Connection removed -586303861 from server ActiveMQServerImpl::serverUUID=ff4f71ba-5e2b-11e6-8283-685b35bfdcae
java.lang.Exception: trace
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:492)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:675)
at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelInactive(ActiveMQChannelHandler.java:75)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:208)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:194)
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:828)
at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:625)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745)
2016-08-09T13:28:11,720 319123 [Thread-4 (activemq-netty-threads-746685035)] DEBUG o.a.a.a.c.r.s.i.RemotingServiceImpl - RemotingServiceImpl::removing connection ID -586303861


This looks like a transaction is being rolled back, I haven't knowingly asked for a transaction and I have no idea what I should be doing to commit a transaction if one is being created for me...

Cheers, Andy

-----Original Message-----
From: Andy Redhead
Sent: 09 August 2016 13:01
To: users@activemq.apache.org; 'mtaylor@redhat.com' <mt...@redhat.com>
Subject: RE: Problems using Qpid Proton-J with Artemis Core

Hi,

I've attached all the files, hopefully they will go through this time (I think I sent the email to users-help rather than users the first time by mistake and didn't re-attach the files when I tried again).

Well spotted on the doc version number, though the same reference to proton-j is referenced in the same section of:

https://activemq.apache.org/artemis/docs/1.3.0/examples.html

I'm running v1.3.0 (and use that as the dependency when building the Artemis server).

One thing I just noticed looking in the new examples documentation page is that on Artemis startup there are log lines for:

Protocol module found: [artemis-server]. Adding protocol support for: CORE
Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP

When my server starts up I only see:

Protocol module found: [artemis-server]. Adding protocol support for: CORE

Perhaps I'm missing some config or a code dependency to get AMPQ support running?

Currently the only Artemis dependency I'm including in the server build is:

compile group: 'org.apache.activemq', name: 'artemis-server', version: '1.3.0'

Cheers, Andy

-----Original Message-----
From: Martyn Taylor [mailto:mtaylor@redhat.com]
Sent: 09 August 2016 12:32
To: users@activemq.apache.org
Subject: Re: Problems using Qpid Proton-J with Artemis Core

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 <an...@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!
>
***** 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

Re: Problems using Qpid Proton-J with Artemis Core

Posted by "John D. Ament" <jo...@apache.org>.
Andy,

Sorry, maybe missed a step here.  What does your client look like? What are
its maven dependencies?

FWIW, I would expect amqp to work regardless of underlying impl.  May be
something is missing from your side, or you're using the artemis client
under the hood?

John

On Tue, Aug 9, 2016 at 9:24 AM Andy Redhead <an...@oneadvanced.com>
wrote:

> Hi,
>
> Thanks for that, with both “artemis-amqp-protocol” and
> “artemis-proton-plug” included in the server and making sure that the
> producer and consumer were using the address “amqp://localhost:5672/ctest”
> it all works ☺
>
> Out of interest, if qpid proton is a server agnostic AMQP client, why does
> the server need the artemis-proton-plug dependency?
>
> For the doco glitch I’ve created Jira ticket:
>
> https://issues.apache.org/jira/browse/ARTEMIS-674
>
> Cheers, Andy
>
> From: Martyn Taylor [mailto:mtaylor@redhat.com]
> Sent: 09 August 2016 13:40
> To: Andy Redhead <an...@oneadvanced.com>
> Subject: Re: Problems using Qpid Proton-J with Artemis Core
>
>
> On Tue, Aug 9, 2016 at 1:01 PM, Andy Redhead <an...@oneadvanced.com>
> wrote:
> Hi,
>
> I've attached all the files, hopefully they will go through this time (I
> think I sent the email to users-help rather than users the first time by
> mistake and didn't re-attach the files when I tried again).
>
> Well spotted on the doc version number, though the same reference to
> proton-j is referenced in the same section of:
>
> https://activemq.apache.org/artemis/docs/1.3.0/examples.html
> Thanks for the info.  Could you open a JIRA to report the missing example
> and we'll get things updated:
> https://issues.apache.org/jira/browse/ARTEMIS
>
>
> I'm running v1.3.0 (and use that as the dependency when building the
> Artemis server).
>
> One thing I just noticed looking in the new examples documentation page is
> that on Artemis startup there are log lines for:
>
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> Protocol module found: [artemis-amqp-protocol]. Adding protocol support
> for: AMQP
>
> When my server starts up I only see:
>
> Protocol module found: [artemis-server]. Adding protocol support for: CORE
> This looks like you don't have the proper protocol module libraries on
> your class path.  Add the following libraries to enable AMQP:
>
> <dependency>
>     <groupId>org.apache.activemq</groupId>
>     <artifactId>artemis-proton-plug</artifactId>
>     <version>1.3.0</version>
> </dependency>
>
> <dependency>
>     <groupId>org.apache.activemq</groupId>
>     <artifactId>artemis-amqp-protocol</artifactId>
>     <version>1.3.0</version>
> </dependency>
>
> Perhaps I'm missing some config or a code dependency to get AMPQ support
> running?
>
> Currently the only Artemis dependency I'm including in the server build is:
>
> compile group: 'org.apache.activemq', name: 'artemis-server', version:
> '1.3.0'
>
> Cheers, Andy
>
> -----Original Message-----
> From: Martyn Taylor [mailto:mtaylor@redhat.com]
> Sent: 09 August 2016 12:32
> To: users@activemq.apache.org
> Subject: Re: Problems using Qpid Proton-J with Artemis Core
>
> 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!
> >
> ***** 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
>
> ***** 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
>

Re: Problems using Qpid Proton-J with Artemis Core

Posted by Martyn Taylor <mt...@redhat.com>.
Apologies I hit the "reply" and not "reply list".

Posting to list for others.

Thanks.

On Tue, Aug 9, 2016 at 2:47 PM, Martyn Taylor <mt...@redhat.com> wrote:

>
>
> On Tue, Aug 9, 2016 at 2:24 PM, Andy Redhead <andy.redhead@oneadvanced.com
> > wrote:
>
>> Hi,
>>
>> Thanks for that, with both “artemis-amqp-protocol” and
>> “artemis-proton-plug” included in the server and making sure that the
>> producer and consumer were using the address “amqp://localhost:5672/ctest”
>> it all works ☺
>>
> Good to hear.
>
>>
>> Out of interest, if qpid proton is a server agnostic AMQP client, why
>> does the server need the artemis-proton-plug dependency?
>
>
> The proton plug module is currently required as part of the Artemis AMQP
> implementation; we use Proton server side to handle decoding of packets,
> protocol state and such.  Any AMQP 1.0 compatible client should work.
>
Just to be clear.  This proton-plug is not just required to allow proton
clients to connect.

The two components together make up the AMQP protocol implementation.  The
proton plug module deals with lower level AMQP details, decoding frames,
handling the protocol state machine, then creating appropriate events which
are then captured in the AMQP protocol module.

During the processing of these events, the AMQP protocol module interacts
with the broker core API to perform the relevant tasks, store messages,
start transaction etc....

>
> We'll be doing some refactoring around AMQP in the upcoming months, the
> result of this will likely be the merger of proton-plug and the amqp
> protocol module.
>
>>
>> For the doco glitch I’ve created Jira ticket:
>>
>> https://issues.apache.org/jira/browse/ARTEMIS-674
>
> Thank you.
>
>>
>>
>> Cheers, Andy
>>
>> From: Martyn Taylor [mailto:mtaylor@redhat.com]
>> Sent: 09 August 2016 13:40
>> To: Andy Redhead <an...@oneadvanced.com>
>> Subject: Re: Problems using Qpid Proton-J with Artemis Core
>>
>>
>> On Tue, Aug 9, 2016 at 1:01 PM, Andy Redhead <
>> andy.redhead@oneadvanced.com> wrote:
>> Hi,
>>
>> I've attached all the files, hopefully they will go through this time (I
>> think I sent the email to users-help rather than users the first time by
>> mistake and didn't re-attach the files when I tried again).
>>
>> Well spotted on the doc version number, though the same reference to
>> proton-j is referenced in the same section of:
>>
>> https://activemq.apache.org/artemis/docs/1.3.0/examples.html
>> Thanks for the info.  Could you open a JIRA to report the missing example
>> and we'll get things updated: https://issues.apache.org/jira
>> /browse/ARTEMIS
>>
>>
>> I'm running v1.3.0 (and use that as the dependency when building the
>> Artemis server).
>>
>> One thing I just noticed looking in the new examples documentation page
>> is that on Artemis startup there are log lines for:
>>
>> Protocol module found: [artemis-server]. Adding protocol support for: CORE
>> Protocol module found: [artemis-amqp-protocol]. Adding protocol support
>> for: AMQP
>>
>> When my server starts up I only see:
>>
>> Protocol module found: [artemis-server]. Adding protocol support for: CORE
>> This looks like you don't have the proper protocol module libraries on
>> your class path.  Add the following libraries to enable AMQP:
>>
>> <dependency>
>>     <groupId>org.apache.activemq</groupId>
>>     <artifactId>artemis-proton-plug</artifactId>
>>     <version>1.3.0</version>
>> </dependency>
>>
>> <dependency>
>>     <groupId>org.apache.activemq</groupId>
>>     <artifactId>artemis-amqp-protocol</artifactId>
>>     <version>1.3.0</version>
>> </dependency>
>>
>> Perhaps I'm missing some config or a code dependency to get AMPQ support
>> running?
>>
>> Currently the only Artemis dependency I'm including in the server build
>> is:
>>
>> compile group: 'org.apache.activemq', name: 'artemis-server', version:
>> '1.3.0'
>>
>> Cheers, Andy
>>
>> -----Original Message-----
>> From: Martyn Taylor [mailto:mtaylor@redhat.com]
>> Sent: 09 August 2016 12:32
>> To: users@activemq.apache.org
>> Subject: Re: Problems using Qpid Proton-J with Artemis Core
>>
>> 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!
>> >
>> ***** 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
>>
>> ***** 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
>>
>
>

RE: Problems using Qpid Proton-J with Artemis Core

Posted by Andy Redhead <an...@oneadvanced.com>.
Hi,

Thanks for that, with both “artemis-amqp-protocol” and “artemis-proton-plug” included in the server and making sure that the producer and consumer were using the address “amqp://localhost:5672/ctest” it all works ☺

Out of interest, if qpid proton is a server agnostic AMQP client, why does the server need the artemis-proton-plug dependency?

For the doco glitch I’ve created Jira ticket:

https://issues.apache.org/jira/browse/ARTEMIS-674

Cheers, Andy

From: Martyn Taylor [mailto:mtaylor@redhat.com]
Sent: 09 August 2016 13:40
To: Andy Redhead <an...@oneadvanced.com>
Subject: Re: Problems using Qpid Proton-J with Artemis Core


On Tue, Aug 9, 2016 at 1:01 PM, Andy Redhead <an...@oneadvanced.com> wrote:
Hi,

I've attached all the files, hopefully they will go through this time (I think I sent the email to users-help rather than users the first time by mistake and didn't re-attach the files when I tried again).

Well spotted on the doc version number, though the same reference to proton-j is referenced in the same section of:

https://activemq.apache.org/artemis/docs/1.3.0/examples.html
Thanks for the info.  Could you open a JIRA to report the missing example and we'll get things updated: https://issues.apache.org/jira/browse/ARTEMIS


I'm running v1.3.0 (and use that as the dependency when building the Artemis server).

One thing I just noticed looking in the new examples documentation page is that on Artemis startup there are log lines for:

Protocol module found: [artemis-server]. Adding protocol support for: CORE
Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP

When my server starts up I only see:

Protocol module found: [artemis-server]. Adding protocol support for: CORE
This looks like you don't have the proper protocol module libraries on your class path.  Add the following libraries to enable AMQP:

<dependency>
    <groupId>org.apache.activemq</groupId>
    <artifactId>artemis-proton-plug</artifactId>
    <version>1.3.0</version>
</dependency>

<dependency>
    <groupId>org.apache.activemq</groupId>
    <artifactId>artemis-amqp-protocol</artifactId>
    <version>1.3.0</version>
</dependency>

Perhaps I'm missing some config or a code dependency to get AMPQ support running?

Currently the only Artemis dependency I'm including in the server build is:

compile group: 'org.apache.activemq', name: 'artemis-server', version: '1.3.0'

Cheers, Andy

-----Original Message-----
From: Martyn Taylor [mailto:mtaylor@redhat.com]
Sent: 09 August 2016 12:32
To: users@activemq.apache.org
Subject: Re: Problems using Qpid Proton-J with Artemis Core

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 <an...@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!
>
***** 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

***** 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

RE: Problems using Qpid Proton-J with Artemis Core

Posted by Andy Redhead <an...@oneadvanced.com>.
Hi,

I've attached all the files, hopefully they will go through this time (I think I sent the email to users-help rather than users the first time by mistake and didn't re-attach the files when I tried again).

Well spotted on the doc version number, though the same reference to proton-j is referenced in the same section of:

https://activemq.apache.org/artemis/docs/1.3.0/examples.html

I'm running v1.3.0 (and use that as the dependency when building the Artemis server).

One thing I just noticed looking in the new examples documentation page is that on Artemis startup there are log lines for:

Protocol module found: [artemis-server]. Adding protocol support for: CORE
Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP

When my server starts up I only see:

Protocol module found: [artemis-server]. Adding protocol support for: CORE

Perhaps I'm missing some config or a code dependency to get AMPQ support running?

Currently the only Artemis dependency I'm including in the server build is:

compile group: 'org.apache.activemq', name: 'artemis-server', version: '1.3.0'

Cheers, Andy

-----Original Message-----
From: Martyn Taylor [mailto:mtaylor@redhat.com]
Sent: 09 August 2016 12:32
To: users@activemq.apache.org
Subject: Re: Problems using Qpid Proton-J with Artemis Core

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 <an...@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!
>
***** 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

Re: Problems using Qpid Proton-J with Artemis Core

Posted by Martyn Taylor <mt...@redhat.com>.
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 <an...@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!
>