RE: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works on ActiveMQ)
Thank you Gordon and Robbie for the rapid responses. I had my eye on ARTEMIS-46 when looking through the tickets a few minutes ago but the confirmation that it is actually the issue in question is much appreciated -- as is the further info on potential work-arounds. -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 25 April 2016 10:31 To: users@qpid.apache.org Subject: Re: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works on ActiveMQ) On 25 April 2016 at 10:27, Robbie Gemmell wrote: > On 25 April 2016 at 10:02, Gordon Sim wrote: >> On 25/04/16 09:30, Matthew Karlsen wrote: >>> >>> Hello All, >>> >>> Since my last post to this list I have constructed send and recv >>> clients using both JMS and Reactor. Overall they work well and are >>> robust, and fix the issues I was encountering when using Messenger >>> (I was on the wrong track using Reactor at one point but Robbie >>> Gemmell pointed out my mistake; I went away and read the AMQP spec etc. >>> in an effort to understand things better and it appears to have paid >>> off)... >>> >>> However, there is one major problem that I am encountering with Qpid >>> JMS that I am unsure how to resolve... >>> >>> Whether I use receive() with a timeout or receiveNoWait(), receive >>> hangs when no messages are present. More precisely, it hangs at the >>> UNSAFE.park(false, 0L); line of LockSupport.park(): >>> >>> "main@1" prio=5 tid=0x1 nid=NA runnable >>>java.lang.Thread.State: RUNNABLE >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckIn >>> terrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShare >>> dInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedI >>> nterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at >>> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java >>> :97) at >>> org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:764) >>> at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:753) >>> at >>> org.apache.qpid.jms.JmsMessageConsumer.performPullIfRequired(JmsMess >>> ageConsumer.java:627) >>> at >>> org.apache.qpid.jms.JmsMessageConsumer.dequeue(JmsMessageConsumer.ja >>> va:259) >>> at >>> org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.ja >>> va:192) >>> ... >>> >>> Once receive() has locked up it does not resume, even if I >>> subsequently send a message to the appropriate queue. It is >>> eventually shaken out of this state by the broker: >>> "javax.jms.JMSException: Transport closed due to the peer exceeding >>> our requested idle-timeout"... >>> >>> I have tried using both HornetQ and Artemis as the broker. I have >>> also tried ActiveMQ. >>> It does NOT occur on ActiveMQ, so I am wondering if it is in some >>> way related to how the client interacts with a particular broker... >>> >>> Does anyone have any ideas as to what may be going on? >> >> >> Sounds like it is the handling of the drain flag. I found >> https://issues.apache.org/jira/browse/ARTEMIS-46 which may be relevant. >> >> >> > > Hi Matthew > > As Gordon already beat me to saying, this likely arises because > Artemis is not responding [correctly] to 'drain' requests made by the > consumer (https://issues.apache.org/jira/browse/ARTEMIS-46). The > client issues them if the receive timeout expires (or using noWait) > and there isn't yet a message available in the consumers local > prefetch buffer. You can configure the client not to do this by > setting the jms.receiveLocalOnly and/or jms.receiveNoWaitLocalOnly URI > option to false Erm..by setting them to true, obviously :) > (http://qpid.apache.org/releases/qpid-jms-0.9.0/docs/index.html#connection-uri). > Note that in the case of receiveNoWait (and browsers) in particular > that may then give you different behaviour than expected as it could > then fail to return messages you know are 'on the broker', but havent > yet reached the consumers
Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works on ActiveMQ)
Hello All, Since my last post to this list I have constructed send and recv clients using both JMS and Reactor. Overall they work well and are robust, and fix the issues I was encountering when using Messenger (I was on the wrong track using Reactor at one point but Robbie Gemmell pointed out my mistake; I went away and read the AMQP spec etc. in an effort to understand things better and it appears to have paid off)... However, there is one major problem that I am encountering with Qpid JMS that I am unsure how to resolve... Whether I use receive() with a timeout or receiveNoWait(), receive hangs when no messages are present. More precisely, it hangs at the UNSAFE.park(false, 0L); line of LockSupport.park(): "main@1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:97) at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:764) at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:753) at org.apache.qpid.jms.JmsMessageConsumer.performPullIfRequired(JmsMessageConsumer.java:627) at org.apache.qpid.jms.JmsMessageConsumer.dequeue(JmsMessageConsumer.java:259) at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:192) ... Once receive() has locked up it does not resume, even if I subsequently send a message to the appropriate queue. It is eventually shaken out of this state by the broker: "javax.jms.JMSException: Transport closed due to the peer exceeding our requested idle-timeout"... I have tried using both HornetQ and Artemis as the broker. I have also tried ActiveMQ. It does NOT occur on ActiveMQ, so I am wondering if it is in some way related to how the client interacts with a particular broker... Does anyone have any ideas as to what may be going on? Thank you & regards, Matthew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Reactor Heartbeat [was: RE: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable]
Hello Robbie (and All), Many thanks for the post. I am aware that HornetQ has issues w.r.t. ttl and so on. However, I thought I could send it an empty frame on a regular basis and this would keep the connection alive despite this -- perhaps I was mistaken? I have now tested the connection-ttl-override in Artemis and it works as expected. Unfortunately Artemis is not an option at present... and connection-ttl-override in HornetQ does not work. > It might be possible to tinker via reflection to trick it into thinking it > should be. Thank you for the suggestion -- I will look in to this. > You also mention sending an empty frame, can you elaborate more on what you > are doing exactly? Yes, I can. Incidentally, I modified handleFrame() to be public at present (clearly not a long term solution). Then, on connection init I have the following code: transport = Proton.transport(); transport.bind(connection); transport.setIdleTimeout(0); Open open = new Open(); open.setIdleTimeOut(new UnsignedInteger(0)); TransportFrame openFrame = new TransportFrame(0, open, null); ((TransportImpl) transport).handleFrame(openFrame); [plus a Task t = event.getReactor().schedule(1, this); to schedule a regular event ] Then in onTimerTask() I have the following: byte[] emptyFrame = (new AmqpFramer()).createEmptyFrame(0); ((TransportImpl) transport).input(emptyFrame, 0, emptyFrame.length); Task t = e.getReactor().schedule(1, this); I have experimented with various timeout values but none have achieve the desired result so far. > If you look at the protocol trace (environment variable PN_TRACE_FRM=true) do > you actually see it sending anything? Yes, at present I get a number of [[596512129:0] <- Empty Frame] messages -- however, when I do the same thing with Artemis I get Empty Frames going in both directions, so I suspect HornetQ is not responding correctly. Thank you & regards, Matthew -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 07 April 2016 13:14 To: users@qpid.apache.org Subject: Re: Reactor Heartbeat [was: RE: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable] Hi Matthew, I think your initial issue here is likely that HornetQ is neither requesting clients send it heartbeats, or supporting sending heartbeats to them if it so requested. It is however separately enforcing a timeout in its IO layer. I say that based on the heartbeat handling only quite recently being fixed in ActiveMQ Artemis, which is based on the previously donated HornetQ codebase. In AMQP 1.0 each side announces their own independent timeout requirements to the other side, with each then doing what they need to satisfy the peers requirements, either through normal messaging activity or by explicit heartbeat/empty frames in its absense. The proton engine satisfies/enforces these requirements via the transport tick method, as it seems you might be aware, which checks that requested heartbeats have been received and required heartbeats get sent, returning when it next needs to be called to keep on top of that. The reactor takes care of calling tick itself as far as I am aware and that being the case you also calling it should have no real effect on overall behaviour, which seems to be what you observed. In any case, if the broker has indeed not advertised an idleTimeout, the tick() will not produce heartbeat/empty frames because it has effectively been told it doesn't need to. It might be possible to tinker via reflection to trick it into thinking it should be. You also mention sending an empty frame, can you elaborate more on what you are doing exactly? If you look at the protocol trace (envieonment variable PN_TRACE_FRM=true) do you actually see it sending anything? The heartbeating stuff is all hidden behind tick(), so are you achieving that via reflection? Robbie On 6 April 2016 at 10:20, Matthew Karlsen wrote: > Hello All, > > After being directed towards the Proton-J reactor (away from the messenger), > I have been experimenting with reactor. I modified the supplied reactor > examples to send/recv to/from a queue on HornetQ fairly quickly. > > However, I appear to be having less success implementing a > heartbeat/keep-alive (HornetQ 2.4.0 will disconnect after a one minute > default if it does not receive data from the client). > > I have scheduled a regular event using [ e.getReactor().schedule(1, > this); ] with a view to implementing a heartbeat. I then override > onTimerTask() and call tick() or send an empty frame within onTimerTask() > then re-schedule another call of onTimerTask() -- I have tried several > permutations. > > However, whether I use tick(), or send an empty frame, it does not seem to > maintain the connection. > > I was wondering: > 1) Are there any better appro
Reactor Heartbeat [was: RE: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable]
Hello All, After being directed towards the Proton-J reactor (away from the messenger), I have been experimenting with reactor. I modified the supplied reactor examples to send/recv to/from a queue on HornetQ fairly quickly. However, I appear to be having less success implementing a heartbeat/keep-alive (HornetQ 2.4.0 will disconnect after a one minute default if it does not receive data from the client). I have scheduled a regular event using [ e.getReactor().schedule(1, this); ] with a view to implementing a heartbeat. I then override onTimerTask() and call tick() or send an empty frame within onTimerTask() then re-schedule another call of onTimerTask() -- I have tried several permutations. However, whether I use tick(), or send an empty frame, it does not seem to maintain the connection. I was wondering: 1) Are there any better approaches? 2) What is the "correct" approach/location for using tick()? Thank you & regards, Matthew -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 18 March 2016 17:59 To: users@qpid.apache.org Subject: Re: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable On 18 March 2016 at 12:15, Matthew Karlsen wrote: > Hello All, > > We have a queue running in HornetQ 2.4.0 (embedded within Wildfly), with a > Proton-J 0.12.0 client periodically connecting to this queue. > > If HornetQ stops or becomes unavailable when the Proton-J client is running, > the Proton-J client continually generates exceptions similar to that below > (very rapidly). > > The issue is that the IOException generated exception is handled in > MessengerImpl's processActive() by generating an "Error processing > connection" message in the logs, rather than recv() throwing an exception and > hence the higher level program logic is unable to react to the problem. > > Is this a bug or am I missing something important? > > Thank you, > Matthew > > java.io.IOException: An existing connection was forcibly closed by the remote > host > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) > at sun.nio.ch.IOUtil.read(IOUtil.java:197) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) > at > org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:129) > at > org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:94) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:738) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:895) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:844) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:446) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:451) > ... > at java.lang.Thread.run(Thread.java:745) > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > additional commands, e-mail: users-h...@qpid.apache.org > Hi Matthew, It certainly doesnt seem desirable, I'd guess its a bug, though someone actually familiar with Messenger could certainly correct me on that. Messenger isn't widely used on the proton-j side, and in general Messenger isn't getting much developer attention these days (arguably never did in proton-j, which is mostly still used as an pure protocol engine as intended at the outset) since folks are concentrated more on newer reactive APIs. Proton-J is a bit behind the curve in terms of the higher level reactive work being/already done in some of the other lanaguages (something I'll be looking to get to), but there was a Java port done of the 'reactor' that exists in proton-c and some of its bindings. I'm not particularly familiar with it either, or how it would handle this situation, but it may be worth you looking at as alternative to Messenger. You can see some example of it in the examples/java/reactor dir, e.g. the Send class (the Recv class in this case is actually a server/listener that accepts incoming connections, such as those made by Send). Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable
Hello Robbie, Thank you very much for the information. I'll check out the Java port of the Reactor. Regards, Matthew -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 18 March 2016 17:59 To: users@qpid.apache.org Subject: Re: Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable On 18 March 2016 at 12:15, Matthew Karlsen wrote: > Hello All, > > We have a queue running in HornetQ 2.4.0 (embedded within Wildfly), with a > Proton-J 0.12.0 client periodically connecting to this queue. > > If HornetQ stops or becomes unavailable when the Proton-J client is running, > the Proton-J client continually generates exceptions similar to that below > (very rapidly). > > The issue is that the IOException generated exception is handled in > MessengerImpl's processActive() by generating an "Error processing > connection" message in the logs, rather than recv() throwing an exception and > hence the higher level program logic is unable to react to the problem. > > Is this a bug or am I missing something important? > > Thank you, > Matthew > > java.io.IOException: An existing connection was forcibly closed by the remote > host > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) > at sun.nio.ch.IOUtil.read(IOUtil.java:197) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) > at > org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:129) > at > org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:94) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:738) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:895) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:844) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:446) > at > org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:451) > ... > at java.lang.Thread.run(Thread.java:745) > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > additional commands, e-mail: users-h...@qpid.apache.org > Hi Matthew, It certainly doesnt seem desirable, I'd guess its a bug, though someone actually familiar with Messenger could certainly correct me on that. Messenger isn't widely used on the proton-j side, and in general Messenger isn't getting much developer attention these days (arguably never did in proton-j, which is mostly still used as an pure protocol engine as intended at the outset) since folks are concentrated more on newer reactive APIs. Proton-J is a bit behind the curve in terms of the higher level reactive work being/already done in some of the other lanaguages (something I'll be looking to get to), but there was a Java port done of the 'reactor' that exists in proton-c and some of its bindings. I'm not particularly familiar with it either, or how it would handle this situation, but it may be worth you looking at as alternative to Messenger. You can see some example of it in the examples/java/reactor dir, e.g. the Send class (the Recv class in this case is actually a server/listener that accepts incoming connections, such as those made by Send). Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Rapid generation of IOExceptions on Proton-J client recv() when HornetQ stopped/becomes unavailable
Hello All, We have a queue running in HornetQ 2.4.0 (embedded within Wildfly), with a Proton-J 0.12.0 client periodically connecting to this queue. If HornetQ stops or becomes unavailable when the Proton-J client is running, the Proton-J client continually generates exceptions similar to that below (very rapidly). The issue is that the IOException generated exception is handled in MessengerImpl's processActive() by generating an "Error processing connection" message in the logs, rather than recv() throwing an exception and hence the higher level program logic is unable to react to the problem. Is this a bug or am I missing something important? Thank you, Matthew java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:129) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:94) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:738) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:895) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:844) at org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:446) at org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java:451) ... at java.lang.Thread.run(Thread.java:745) - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: Newbie Question: Adding Fields/Properties to Messages
You can. See https://qpid.apache.org/releases/qpid-proton-0.11.1/proton/java/api/org/apache/qpid/proton/message/impl/MessageImpl.html#setApplicationProperties%28org.apache.qpid.proton.amqp.messaging.ApplicationProperties%29 for instance. Regards, Matthew -Original Message- From: Flores, Paul A. [mailto:paul.a.flo...@saic.com] Sent: 08 February 2016 15:59 To: users@qpid.apache.org Subject: RE: Newbie Question: Adding Fields/Properties to Messages I see setProperty() in C++ Client API Message. Does that imply I can add custom properties to a message? May be a different question but why is setProperty() not a part of Proton? From: Chuck Rolke [cro...@redhat.com] Sent: Monday, February 08, 2016 9:29 AM To: users@qpid.apache.org Subject: Re: Newbie Question: Adding Fields/Properties to Messages Start at http://qpid.apache.org/documentation.html Using the Qpid Messaging API you can get at the message properties in a variety of languages. - Original Message - > From: "Paul A. Flores" > To: users@qpid.apache.org > Sent: Monday, February 8, 2016 10:20:21 AM > Subject: Newbie Question: Adding Fields/Properties to Messages > > Hi, > > I' new to the QPID and just evaluating which aspect to utilize in a project. > One project requirement is to use a preset list of message > fields/properties. > > > > My question is really quite straightforward, what exists that would > allow me to customize message fields/properties? > > > > Thanks for your time and guidance. > > > > Paul > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Sending/retrieving larger messages using Proton-J?
Hello all, I am presently trying to send a 1.4 meg PDF in a message and am encountering substantial difficulties. I have tried various combinations (though my central aim is to use Proton-J). Combinations as follows: Qpid Proton-J 0.11.1 to HornetQ 2.4.0 Final to Qpid Proton-J 0.11.1 Qpid Proton-J 0.11.1 to Apache Artemis 1.2.0 to Qpid Proton-J 0.11.1 Qpid JMS 0.7 to HornetQ 2.4.0 Final to Qpid JMS 0.7 Qpid JMS 0.7 to Apache Artemis 1.2.0 to Qpid JMS 0.7 Have also tried MQLight and SwiftMQ clients (though they are not really a viable solution here due to their licenses). The most bytes I have managed to send and receive is ~10,000. I frequently get the two error messages below when sending (in the Artemis console window) -- relating to the Qpid Proton library. (Note: I have tried increasing connection-ttl on the client side.) My question is this: are there any important caveats when sending large messages via AMQP that I have somehow missed (or related caveats)? I have read the Qpid documentation, HornetQ documentation and Apache Artemis documentation and there are some things that I think *may* be relevant, but I am not sure. The question is clearly somewhat cross-technology but I felt that this was the best place to post the issue. I am happy to supply Wireshark output if required, though I suspect the output would be quite voluminous. Thank you for any help you are able to offer, regards, Matthew - java.nio.BufferUnderflowException at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151) at org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:939) at org.apache.qpid.proton.codec.BinaryType$LongBinaryEncoding.readValue(BinaryType.java:110) at org.apache.qpid.proton.codec.BinaryType$LongBinaryEncoding.readValue(BinaryType.java:67) at org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39) at org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885) at org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:647) at org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:577) at org.apache.qpid.proton.jms.EncodedMessage.decode(EncodedMessage.java:46) at org.apache.qpid.proton.jms.JMSMappingInboundTransformer.transform(JMSMappingInboundTransformer.java:40) at org.apache.activemq.artemis.core.protocol.proton.converter.ProtonMessageConverter.inboundJMSType(ProtonMessageConverter.java:57) at org.apache.activemq.artemis.core.protocol.proton.converter.ProtonMessageConverter.inbound(ProtonMessageConverter.java:43) at org.apache.activemq.artemis.core.protocol.proton.plug.ProtonSessionIntegrationCallback.serverSend(ProtonSessionIntegrationCallback.java:249) at org.proton.plug.context.server.ProtonServerReceiverContext.onMessage(ProtonServerReceiverContext.java:116) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onDelivery(AbstractConnectionContext.java:250) at org.proton.plug.handler.Events.dispatch(Events.java:100) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:339) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:259) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:159) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:82) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:128) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:620) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) at java.lang.Thread.run(Thread.java:745) 14:45:05,373 WARN [org.apache.a
RE: download file contains almost nothing
That link is to the download page, you then choose a mirror to download from. (I have previously made that mistake too.) Regards, Matthew -Original Message- From: WANG Hui [mailto:hui.w...@murex.com] Sent: 26 January 2016 10:30 To: users@qpid.apache.org Subject: download file contains almost nothing Hello All, Does anyone else notice that the download file is too small ? It's around 5k http://www.apache.org/dyn/closer.lua/qpid/0.32/qpid-java-0.32.tar.gz Thanks, Hui *** This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: "unknown frame type: 0" after upgrading proton-j jar and proton jms jar (0.4 -> 0.10) in HornetQ (final).
Hello All, Many thanks for the continued responses. In response to Gordon Sim -- the protocol header being sent is AMQP 03 01 00 00 -- so, 03 is in the correct place I think. In response, I get back AMQP 00 01 00 00 -- I think Chuck Rolke was correct earlier when he said "It sounds like the java code is expecting a Sasl header (type 3) but is receiving a normal AMQP header (type 0).". The only response I get back from HornetQ (when I try to connect locally) is: > 15:15:10,963 WARN [org.hornetq.core.server] HQ222067: Connection failure has > been detected: HQ119014: Did not receive data from > /127.0.0.1:54377. It is likely the client has exited or crashed without > closing its connection, or the network between the server and client has > failed. You also might have configured connection-ttl and > client-failure-check-period incorrectly. Please check user manual for > more information. The connection will now be closed. > [code=CONNECTION_TIMEDOUT] So, it looks as if it *'thinks'* it is responding correctly... As Robbie Gemmell says: > I'm a little uncertain from your description as to whether you are also > trying to update the jars used by HornetQ itself. I'd be quite surprised if > that worked (unless you are updating the source as needed and rebuilding?) > since it's a significant version+time difference that the API wasn't very > stable across, particularly with the earlier of those versions, but > regardless...changing them also wouldn't significantly alter the idle timeout > behaviour since the brokers use of the protocol engine would still need > updated to actually hook up the idle-timeout config+handling. I was just dropping in the jars (renamed to use the existing names). I realise that this is a bit of a long shot, but cannot get the additional time to modify the source e.t.c. at the moment. This info is really useful since it seems as if what I am trying to do is a dead end... I may just have to wait for Wildfly 10 (which can embed Artemis, which uses the required updated Qpid libraries, which will enable me to keep connections alive longer than 60 seconds, if I understand correctly! To summarise, unless anyone knows of a quick fix (which seems unlikely from the above) I'll have to work round it for now. Thanks again for all the help everyone. Regards, Matthew -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 28 October 2015 13:12 To: users@qpid.apache.org Subject: Re: "unknown frame type: 0" after upgrading proton-j jar and proton jms jar (0.4 -> 0.10) in HornetQ (final). The 0.4 release of proton-j had no support for idle-timeout handling and didn't enable configuring a value for the advertised idle-timeout fieldin the Open frame, so it could neither request heartbeats be sent to it, or send them if request was made by another peer. Any hard-coded timeouts mentioned at the link are presumably within HornetQ, at a layer outwith proton-j, e.g the IO layer. The proton-j engine does now support configuring/enforcing/satisfying idle-timeout behaviour, if so utilised by consuming components. I don't see any obvious indication of that support having been used within 'messenger-j', in which case it still wouldnt be able to send heartbeat frames to the peer if so requested, and also couldn't request the peer send it heartbeats. I'm a little uncertain from your description as to whether you are also trying to update the jars used by HornetQ itself. I'd be quite surprised if that worked (unless you are updating the source as needed and rebuilding?) since its a significant version+time difference that the API wasnt very stableacross, particularly with the earlier of those versions, but regardless...changing them also wouldnt significantly alter the idle timeout behaviour since the brokers use of the protocol engine would still need updated to actually hook up the idle-timeout config+handling. Robbie On 28 October 2015 at 12:08, Matthew Karlsen wrote: > Hello, > > Thank you both very much for taking the trouble to respond. > > I'm unsure how to disable sasl in Qpid Proton but will try and work it out. > > I was having trouble with Wireshark, but have now got it working. > The protocol interaction in Wireshark (when executing a simple Qpid Proton > send example) is included below. Apologies for not sending this initially. > > I have also included the send "test code", below. > > The server running is HornetQ 2.4.0.Final with the proton-j and proton jms > jars upgraded (to 0.10, from 0.4). > > Thanks & regards, > Matthew > > > ## WIRESHARK OUTPUT ## > > No. TimeSourceDestination Protocol > Length Info &g
RE: "unknown frame type: 0" after upgrading proton-j jar and proton jms jar (0.4 -> 0.10) in HornetQ (final).
ress);
System.out.println("Set subject");
//msg.setSubject(subject);
System.out.println("Set delivery annotations");
Map map = new HashMap<>();
map.put(Symbol.getSymbol("modify"), "yes");
DeliveryAnnotations da = new DeliveryAnnotations(map);
msg.setDeliveryAnnotations(da);
System.out.println("Set message body");
Section s = new AmqpValue(body);
msg.setBody(s);
mng.put(msg);
System.out.println("Send message");
try {
mng.send();
} catch (TimeoutException e){
e.printStackTrace();
}
System.out.println("Stop messenger");
mng.stop();
} catch (Exception e) {
tracer.log(Level.SEVERE, "proton error", e);
}
}
}
-Original Message-
From: Chuck Rolke [mailto:cro...@redhat.com]
Sent: 27 October 2015 20:39
To: users@qpid.apache.org
Subject: Re: "unknown frame type: 0" after upgrading proton-j jar and proton
jms jar (0.4 -> 0.10) in HornetQ (final).
- Original Message -
> From: "Gordon Sim"
> To: users@qpid.apache.org
> Sent: Tuesday, October 27, 2015 3:24:37 PM
> Subject: Re: "unknown frame type: 0" after upgrading proton-j jar and
> proton jms jar (0.4 -> 0.10) in HornetQ (final).
>
> On 10/27/2015 03:43 PM, Matthew Karlsen wrote:
> > Hello again,
> >
> > Last time I contacted the list I was having issues with the basic
> > sending and receiving of AMQP messages to/from HornetQ.
> > I have got quite a bit further by myself (+ docs & e.g.s) but am
> > sorry to say that I am stumped again...
> >
> > I have got HornetQ and the Qpid Proton examples configured and
> > working with proton-api-0.4.jar, proton-j-impl-0.4.jar and
> > proton-jms-0.4.jar. I have also set up a divert with a filter such
> > that some messages are diverted from one queue to another.
> >
> > It all works fine...
> >
> > Unfortunately, the Qpid Proton library versions that I am using have
> > a connection timeout hard-coded at 60 seconds (if I understand correctly).
> >
> > I believe this relates to
> > https://developer.jboss.org/thread/233539?start=0&tstart=0 [How to
> > set AMQP idle-timeout / ping frequency / TTL?]
> >
> > As I understand it, upgrading to proton-j-0.10.jar and
> > proton-jms-0.10.jar should fix this issue by letting you specify the
> > timeout.
> >
> > However, with the new jars, when trying to send/receive the message
> > I am getting the error at the end of the message (below).
> >
> > I realise that this topic bridges Qpid and HornetQ (unfortunately).
> > I can confirm that HornetQ does support SASL and my config should be
> > sufficient (indeed, it worked before the upgrade). From the HornetQ
> > manual: "The HornetQ Server accepts AMQP SASL Authentication and
> > will use this to map onto the underlying session created for the
> > connection so you can use the normal HornetQ security configuration."
> >
> > Does anyone have an idea what may be going on?
> >
> > I have tried reading the documentation, wiki, e.t.c. (have spent
> > about a day on this so far).
>
> Can you get a capture of the protocol interaction, e.g. using wireshark?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For
> additional commands, e-mail: users-h...@qpid.apache.org
>
>
It sounds like the java code is expecting a Sasl header (type 3) but is
receiving a normal AMQP header (type 0).
You could try disabling Sasl at your end to see if the connection goes through.
A protocol trace will show for sure.
-Chuck
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
commands, e-mail: users-h...@qpid.apache.org
"unknown frame type: 0" after upgrading proton-j jar and proton jms jar (0.4 -> 0.10) in HornetQ (final).
Hello again, Last time I contacted the list I was having issues with the basic sending and receiving of AMQP messages to/from HornetQ. I have got quite a bit further by myself (+ docs & e.g.s) but am sorry to say that I am stumped again... I have got HornetQ and the Qpid Proton examples configured and working with proton-api-0.4.jar, proton-j-impl-0.4.jar and proton-jms-0.4.jar. I have also set up a divert with a filter such that some messages are diverted from one queue to another. It all works fine... Unfortunately, the Qpid Proton library versions that I am using have a connection timeout hard-coded at 60 seconds (if I understand correctly). I believe this relates to https://developer.jboss.org/thread/233539?start=0&tstart=0 [How to set AMQP idle-timeout / ping frequency / TTL?] As I understand it, upgrading to proton-j-0.10.jar and proton-jms-0.10.jar should fix this issue by letting you specify the timeout. However, with the new jars, when trying to send/receive the message I am getting the error at the end of the message (below). I realise that this topic bridges Qpid and HornetQ (unfortunately). I can confirm that HornetQ does support SASL and my config should be sufficient (indeed, it worked before the upgrade). From the HornetQ manual: "The HornetQ Server accepts AMQP SASL Authentication and will use this to map onto the underlying session created for the connection so you can use the normal HornetQ security configuration." Does anyone have an idea what may be going on? I have tried reading the documentation, wiki, e.t.c. (have spent about a day on this so far). Thanks & regards, Matthew Oct 27, 2015 2:48:47 PM org.apache.qpid.proton.driver.impl.ConnectorImpl read SEVERE: ConnectorImpl [_channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:52583 remote=localhost/127.0.0.1:5672]] error processing input org.apache.qpid.proton.engine.TransportException: unknown frame type: 0 at org.apache.qpid.proton.engine.impl.SaslFrameParser.input(SaslFrameParser.java:183) at org.apache.qpid.proton.engine.impl.SaslImpl$SaslTransportWrapper.reallyProcessInput(SaslImpl.java:630) at org.apache.qpid.proton.engine.impl.SaslImpl$SaslTransportWrapper.process(SaslImpl.java:601) at org.apache.qpid.proton.engine.impl.HandshakeSniffingTransportWrapper.process(HandshakeSniffingTransportWrapper.java:101) at org.apache.qpid.proton.engine.impl.TransportImpl.process(TransportImpl.java:1415) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:135) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:94) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:738) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:890) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:839) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:417) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:394) at qpid.SendOld.run(SendOld.java:93) at qpid.SendOld.main(SendOld.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
RE: Basic send/receive AMQP message to HornetQ server using Python
Many thanks for the response. I checked the manual and HornetQ does support SASL and AMQP is enabled. The issue (solved with assistance from Justin Bertram on the Jboss forums: https://developer.jboss.org/thread/265676) was a misunderstanding concerning queue configuration. Just in case anyone else tries to do the same thing and finds this, the "correct" config I used included: exampleQueue1 true exampleQueue2 true And org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory With these changes (primarily a queue address change) the example works. Thanks again for the help, and for pointing me to Wireshark which is really useful! -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: 23 October 2015 10:09 To: users@qpid.apache.org Subject: Re: Basic send/receive AMQP message to HornetQ server using Python On 10/23/2015 09:00 AM, Matthew Karlsen wrote: > Hello, > > I am currently attempting to use the code on > https://qpid.apache.org/releases/qpid-proton-0.10/proton/python/tutorial/tutorial.html > to send and receive a message to a HornetQ server. > > (Slightly modified code below...) > > I have set up a HornetQ core queue called exampleQueue1 to connect to and am > running the server. I get, e.g. "08:29:28,247 INFO [org.hornetq.core.server] > HQ221003: trying to deploy queue exampleQueue1" on the server console. > > I have compiled the required c code for the example to run properly. > > When I run the example below I get "ERROR:root:amqp:connection:framing-error: > SASL header mismatch: Insufficient data to determine protocol [''] > (connection aborted)" repeatedly until I kill the program. > > I have googled this error but get very few hits and have not found one that > is sufficiently explanatory. > > I will continue to try to work out how to solve this issue. However, I was > wondering if anyone could assist with this question? It sounds like the client is sending the SASL AMQP protocol header, and the broker is not replying as expected with an AMQP protocol header. You could verify that by running wireshark. Setting PN_TRACE_FRM=1 while running the client will also print some details (but that is the client's view). Is AMQP definitely enabled on the broker? Does the version in use support SASL? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Basic send/receive AMQP message to HornetQ server using Python
Hello,
I am currently attempting to use the code on
https://qpid.apache.org/releases/qpid-proton-0.10/proton/python/tutorial/tutorial.html
to send and receive a message to a HornetQ server.
(Slightly modified code below...)
I have set up a HornetQ core queue called exampleQueue1 to connect to and am
running the server. I get, e.g. "08:29:28,247 INFO [org.hornetq.core.server]
HQ221003: trying to deploy queue exampleQueue1" on the server console.
I have compiled the required c code for the example to run properly.
When I run the example below I get "ERROR:root:amqp:connection:framing-error:
SASL header mismatch: Insufficient data to determine protocol [''] (connection
aborted)" repeatedly until I kill the program.
I have googled this error but get very few hits and have not found one that is
sufficiently explanatory.
I will continue to try to work out how to solve this issue. However, I was
wondering if anyone could assist with this question?
Thanks & regards,
Matthew
from __future__ import print_function
from proton import Message
from proton.handlers import MessagingHandler
from proton.reactor import Container
class HelloWorld(MessagingHandler):
def __init__(self, server, address):
super(HelloWorld, self).__init__()
self.server = server
self.address = address
def on_start(self, event):
conn = event.container.connect(self.server)
event.container.create_receiver(conn, self.address)
event.container.create_sender(conn, self.address)
def on_sendable(self, event):
event.sender.send(Message(body="Hello World!"))
event.sender.close()
def on_message(self, event):
print(event.message.body)
event.connection.close()
helloWorld = HelloWorld("amqp://guest:guest@localhost:5672", "exampleQueue1")
Container(helloWorld).run()
