[jira] [Commented] (QPID-5379) [AMQP 1.0] Sasl layer with encryption is broken
[ https://issues.apache.org/jira/browse/QPID-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836411#comment-13836411 ] ASF subversion and git services commented on QPID-5379: --- Commit 1546952 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1546952 ] QPID-5379: missing export directive for windows [AMQP 1.0] Sasl layer with encryption is broken --- Key: QPID-5379 URL: https://issues.apache.org/jira/browse/QPID-5379 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.26 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.27 E.g. if using DIGEST-MD5 with default ssf. The client will print an error and core dump after the authentication completes. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5367) Dispatch - Add man pages and stubs for other documentation
[ https://issues.apache.org/jira/browse/QPID-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836470#comment-13836470 ] ASF subversion and git services commented on QPID-5367: --- Commit 1546978 from [~justi9] in branch 'dispatch/trunk' [ https://svn.apache.org/r1546978 ] QPID-5367: Add a man page for qdrouterd; move cmake logic for docs to its own file Dispatch - Add man pages and stubs for other documentation -- Key: QPID-5367 URL: https://issues.apache.org/jira/browse/QPID-5367 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Justin Ross Assignee: Justin Ross - Man pages for qdstat, qdrouterd, and qdrouterd.conf - Start a book for more involved documentation, and port some of the content from the website - Add a place for developer notes; add a note about code conventions - Add a place for api doc resources such as an overview for doxygen -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5380) Dispatch - Simplify use of non-system instances
Justin Ross created QPID-5380: - Summary: Dispatch - Simplify use of non-system instances Key: QPID-5380 URL: https://issues.apache.org/jira/browse/QPID-5380 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Justin Ross Assignee: Justin Ross Right now the config path is set to /etc/qpid-dispatch/... in every instance, and the user needs to override it. For checkouts and other alternate installs, I propose that instead we look to see if QPID_DISPATCH_HOME is set, and if so load config from QPID_DISPATCH_HOME/etc. If we then change QPID_DISPATCH_HOME to be the dispatch build dir, where the configured files land by convention, we'll have an instance that can run without extra args. - Load config from QPID_DISPATCH_HOME/etc if QDH is set; otherwise, use /etc/qpid-dispatch/... - Change the config.sh QPID_DISPATCH_HOME to $(pwd)/build This additionally helps with home-dir installs. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Qpid Java Client with RabbitMQ
Hi,
I am trying to use Qpid Java Client 0.26-Snapshot with RabbitMQ 3.1.3 (using
AMQP 0.9-1). I’ve followed this thread to complete my task :
http://qpid.2158936.n2.nabble.com/Null-Pointer-exception-in-Qpid-Java-CLient-0-24-td7599126.html
It’s running well. In my environnement I’ve two brokers. The one (the A) when
the QPID client is connected, an other one (The B) that is collecting data and
forward them to the A using federation. When a message is coming from the B to
the A the client break with this stack :
1 Nov 2013 13:40:01,595 ERROR BasicMessageConsumer : Caught exception (dump
follows) - ignoring... java.lang.IllegalArgumentException: no such type code:
41at org.apache.qpid.framing.AMQTypeMap.getType(AMQTypeMap.java:46)
at
org.apache.qpid.framing.AMQTypedValue.readFromBuffer(AMQTypedValue.java:211)
at org.apache.qpid.framing.FieldTable.setFromBuffer(FieldTable.java:1078)
at
org.apache.qpid.framing.FieldTable.populateFromBuffer(FieldTable.java:131)
at org.apache.qpid.framing.FieldTable.getProperty(FieldTable.java:112)
at org.apache.qpid.framing.FieldTable.getInteger(FieldTable.java:266)at
org.apache.qpid.client.message.AMQMessageDelegate_0_8.init(AMQMessageDelegate_0_8.java:104)
at
org.apache.qpid.client.message.AbstractJMSMessageFactory.create08MessageWithBody(AbstractJMSMessageFactory.java:103)
at
org.apache.qpid.client.message.AbstractJMSMessageFactory.createMessage(AbstractJMSMessageFactory.java:160)
at
org.apache.qpid.client.message.MessageFactoryRegistry.createMessage(MessageFactoryRegistry.java:127)
at
org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:118)
at
org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:44)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:712)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3327)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3114)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3107)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3250)
at java.lang.Thread.run(Thread.java:722)
This is caused by some header that the RabbitMQ broker set (x-federation). And
because the RabbitMQ broker manage types that are not supported by the Qpid
client I’ve modified the the AMQMessageDelegate_0_8 class and put a try catch
block :try { type = contentHeader.getHeaders().getInteger(
CustomJMSXProperty.JMS_QPID_DESTTYPE.getShortStringName());
} catch (Exception e) { … }
With my rabbitMQ architecture the type is 100% null. In case of federation
between two RabbitMQ brokers I’ve managed to let the type to null and block the
throwed exception. The delivred body content is correct. I don’t know if it
could be a good thing to add this try/catch in a Qpid broker/Qpid client
situation. If you think that this is ok to bypass some header that are not
parseable, perhaps you can add this to you current dev version.
If not I hope this message will help people trying to do the same thing.
Julian
[jira] [Created] (QPID-5381) Dispatch - Use dynamic source address for the reply-to in qdstat tool
Ted Ross created QPID-5381: -- Summary: Dispatch - Use dynamic source address for the reply-to in qdstat tool Key: QPID-5381 URL: https://issues.apache.org/jira/browse/QPID-5381 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Ted Ross Assignee: Ted Ross With dynamic-source available in Proton Messenger (Python - Introduced in 0.6), update the qdstat tool to use a proper dynamic reply-to address. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5380) Dispatch - Simplify use of non-system instances
[ https://issues.apache.org/jira/browse/QPID-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-5380: -- Attachment: QPID-5380-1.patch - Define a default installation area for work inside a checkout - Separate system tests so they can run against an installation - Add qdtest, an entry point for running system tests - Add install logic for qdtest and its system tests - Add test.sh, a developer tool for running all the tests from top to bottom - Update config.sh with variables for in-tree source, build, and install dirs This patch does not address the problem of how to look up the config file when QPID_DISPATCH_HOME is set. That needs some more thought. However, this change by itself is I think an improvement. Dispatch - Simplify use of non-system instances --- Key: QPID-5380 URL: https://issues.apache.org/jira/browse/QPID-5380 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Justin Ross Assignee: Justin Ross Attachments: QPID-5380-1.patch Right now the config path is set to /etc/qpid-dispatch/... in every instance, and the user needs to override it. For checkouts and other alternate installs, I propose that instead we look to see if QPID_DISPATCH_HOME is set, and if so load config from QPID_DISPATCH_HOME/etc. If we then change QPID_DISPATCH_HOME to be the dispatch build dir, where the configured files land by convention, we'll have an instance that can run without extra args. - Load config from QPID_DISPATCH_HOME/etc if QDH is set; otherwise, use /etc/qpid-dispatch/... - Change the config.sh QPID_DISPATCH_HOME to $(pwd)/build This additionally helps with home-dir installs. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5382) Dispatch - Enhance qdstat tool to link usage to users
Ted Ross created QPID-5382: -- Summary: Dispatch - Enhance qdstat tool to link usage to users Key: QPID-5382 URL: https://issues.apache.org/jira/browse/QPID-5382 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Ted Ross The qdstat tool (and the management schema for Dispatch) should be enhanced such that admins can trace address usage (links) to connections/hosts/users. Specifically: - Provide source and target information for links - Identify the connection associated with links - Investigate providing remote pid/process information in connections (like qpidd) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5382) Dispatch - Enhance qdstat tool to link usage to users
[ https://issues.apache.org/jira/browse/QPID-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836807#comment-13836807 ] ASF subversion and git services commented on QPID-5382: --- Commit 1547154 from [~tedross] in branch 'dispatch/trunk' [ https://svn.apache.org/r1547154 ] QPID-5382 - Updated qdstat tool to use dynamic source (available in Proton trunk/0.6). Dispatch - Enhance qdstat tool to link usage to users - Key: QPID-5382 URL: https://issues.apache.org/jira/browse/QPID-5382 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Ted Ross The qdstat tool (and the management schema for Dispatch) should be enhanced such that admins can trace address usage (links) to connections/hosts/users. Specifically: - Provide source and target information for links - Identify the connection associated with links - Investigate providing remote pid/process information in connections (like qpidd) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5381) Dispatch - Use dynamic source address for the reply-to in qdstat tool
[ https://issues.apache.org/jira/browse/QPID-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-5381. Resolution: Fixed Dispatch - Use dynamic source address for the reply-to in qdstat tool - Key: QPID-5381 URL: https://issues.apache.org/jira/browse/QPID-5381 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Reporter: Ted Ross Assignee: Ted Ross With dynamic-source available in Proton Messenger (Python - Introduced in 0.6), update the qdstat tool to use a proper dynamic reply-to address. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Qpid Java Client with RabbitMQ
Hi Julien,
This is as you deduced the result of the RabbitMQ federation adding a
header that the client doenst understand, specifically a Field Array
judging by the thode (41 / 'A' ). Although the particular property being
retrieved at the time of the stacktrace was 'JMS_QPID_DESTTYPE', this is
likely only because it is the first property retrieved and so provokes
decoding the header FieldTable, which the client then discovers contains
the FieldArray which it doesnt understand and leads to an exception being
thrown. By catching that exception you could be masking that it has also
failed to decode a bunch of other subsequent headers, so it probably isn't
a viable general approach. The correct thing would probably be to add
enough support for the client to either decode the array fully (though
there is no real way of exposing such headers except going outwith the JMS
spec) or at least skip it 'properly' by simply reading the appropriate
bytes before continuing to decode the rest. I am unlikely to find time for
this in the near term, but if it is something you wanted to pursue please
feel free to raise a JIRA and attach a patch and I will try to look at it.
Regards,
Robbie
On 29 November 2013 08:50, Julien Poirier jpoir...@hotmail.fr wrote:
Hi,
I am trying to use Qpid Java Client 0.26-Snapshot with RabbitMQ 3.1.3
(using AMQP 0.9-1). I’ve followed this thread to complete my task :
http://qpid.2158936.n2.nabble.com/Null-Pointer-exception-in-Qpid-Java-CLient-0-24-td7599126.html
It’s running well. In my environnement I’ve two brokers. The one (the A)
when the QPID client is connected, an other one (The B) that is collecting
data and forward them to the A using federation. When a message is coming
from the B to the A the client break with this stack :
1 Nov 2013 13:40:01,595 ERROR BasicMessageConsumer : Caught exception
(dump follows) - ignoring... java.lang.IllegalArgumentException: no such
type code: 41at
org.apache.qpid.framing.AMQTypeMap.getType(AMQTypeMap.java:46)at
org.apache.qpid.framing.AMQTypedValue.readFromBuffer(AMQTypedValue.java:211)
at
org.apache.qpid.framing.FieldTable.setFromBuffer(FieldTable.java:1078)
at
org.apache.qpid.framing.FieldTable.populateFromBuffer(FieldTable.java:131)
at
org.apache.qpid.framing.FieldTable.getProperty(FieldTable.java:112)
at org.apache.qpid.framing.FieldTable.getInteger(FieldTable.java:266)
at
org.apache.qpid.client.message.AMQMessageDelegate_0_8.init(AMQMessageDelegate_0_8.java:104)
at
org.apache.qpid.client.message.AbstractJMSMessageFactory.create08MessageWithBody(AbstractJMSMessageFactory.java:103)
at
org.apache.qpid.client.message.AbstractJMSMessageFactory.createMessage(AbstractJMSMessageFactory.java:160)
at
org.apache.qpid.client.message.MessageFactoryRegistry.createMessage(MessageFactoryRegistry.java:127)
at
org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:118)
at
org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:44)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:712)
at
org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3327)
at
org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3114)
at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3107)
at
org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
at
org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3250)
at java.lang.Thread.run(Thread.java:722)
This is caused by some header that the RabbitMQ broker set (x-federation).
And because the RabbitMQ broker manage types that are not supported by the
Qpid client I’ve modified the the AMQMessageDelegate_0_8 class and put a
try catch block :try { type =
contentHeader.getHeaders().getInteger(
CustomJMSXProperty.JMS_QPID_DESTTYPE.getShortStringName());
} catch (Exception e) { … }
With my rabbitMQ architecture the type is 100% null. In case of federation
between two RabbitMQ brokers I’ve managed to let the type to null and block
the throwed exception. The delivred body content is correct. I don’t know
if it could be a good thing to add this try/catch in a Qpid broker/Qpid
client situation. If you think that this is ok to bypass some header that
are not parseable, perhaps you can add this to you current dev version.
If not I hope this message will help people trying to do the same thing.
Julian
