Re: Review Request: IPv6 support for C++ (Windows and Linux) client/broker and python
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1440/#review1407 --- Ship it! - Gordon On 2011-08-11 05:36:00, Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1440/ --- (Updated 2011-08-11 05:36:00) Review request for qpid, Alan Conway, Gordon Sim, Kenneth Giusti, Ted Ross, Steve Huston, and Cliff Jansen. Summary --- This is my proposed code change for C++ and Python to support IPv6: It includes a few different items: IPv6 support at the socket level - The C++ broker now listens on both TCPv4 and TCPv6 sockets for connections and accepts from both in the regular tcp transport. - The C++ client will connect to both TCPv4 and TCPv6 connections. If a name resolves to both v4 and v6 addresses they will be tried in turn as is required for correct functioning in a mixed network. - The necessary Windows code is also present but more lightly tested. - The Python client will now similarly connect to v6 as well as v4 addresses Connection URL syntax and parsing updated to include literal IPv6 addresses - For example [::1] is now allowed - C++ and Python URL parsers updated (very annoying that the parse different syntaxes) Simple system test to the C++ build to smoke test IPv6 support. - This only uses the IPv6 loopback address though I have this change broken down into smaller patches if anyone would rather see it that way. It's just easier to put it up for review in one big glob. This addresses bugs QPID-3404, QPID-3405, QPID-3406, QPID-3407, and QPID-3409. https://issues.apache.org/jira/browse/QPID-3404 https://issues.apache.org/jira/browse/QPID-3405 https://issues.apache.org/jira/browse/QPID-3406 https://issues.apache.org/jira/browse/QPID-3407 https://issues.apache.org/jira/browse/QPID-3409 Diffs - /trunk/qpid/cpp/src/qpid/Address.cpp 1155572 /trunk/qpid/cpp/src/qpid/Url.cpp 1155572 /trunk/qpid/cpp/src/qpid/broker/windows/SslProtocolFactory.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/Socket.h 1155572 /trunk/qpid/cpp/src/qpid/sys/SocketAddress.h 1155572 /trunk/qpid/cpp/src/qpid/sys/TCPIOPlugin.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/epoll/EpollPoller.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/posix/AsynchIO.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/posix/Socket.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/posix/SocketAddress.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/windows/AsynchIoResult.h 1155572 /trunk/qpid/cpp/src/qpid/sys/windows/Socket.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/windows/SocketAddress.cpp 1155572 /trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.h 1155572 /trunk/qpid/cpp/src/tests/CMakeLists.txt 1155572 /trunk/qpid/cpp/src/tests/Makefile.am 1155572 /trunk/qpid/cpp/src/tests/Url.cpp 1155572 /trunk/qpid/cpp/src/tests/cluster_test_logs.py 1155572 /trunk/qpid/cpp/src/tests/ipv6_test PRE-CREATION /trunk/qpid/extras/qmf/src/py/qmf/console.py 1155572 /trunk/qpid/python/qpid/util.py 1155572 /trunk/qpid/tools/src/py/qpid-route 1155572 Diff: https://reviews.apache.org/r/1440/diff Testing --- Tested (amongst other things) with included system test Tested lightly by hand on Windows Thanks, Andrew
[jira] [Commented] (QPID-3403) Empty bindings are not internally pruned from the direct exchange
[ https://issues.apache.org/jira/browse/QPID-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083044#comment-13083044 ] Gordon Sim commented on QPID-3403: -- That's a good suggestion; I've added that test in. Empty bindings are not internally pruned from the direct exchange - Key: QPID-3403 URL: https://issues.apache.org/jira/browse/QPID-3403 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.7 Reporter: Jason Dillaman Assignee: Gordon Sim Priority: Minor Attachments: QPID-3369.patch, QPID-3403.patch Each queue that is created is automatically bound to the default (direct) exchange with a routing key that matches the queue name. When the queue is deleted, the queue is correctly removed from the binding map, but the mapping from routing key to queues is not removed even when there are no queues bound to the routing key. In a case where thousands of uniquely named queues are created and deleted as transient storage, the memory usage of the broker will continue to grow as the default exchange's routing key map continues to grow. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3412) Python and C++ clients translate address differently
Python and C++ clients translate address differently
Key: QPID-3412
URL: https://issues.apache.org/jira/browse/QPID-3412
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10
Environment: Linux
Reporter: Tomas Soltys
I have a following address string
response/response.hey_Joe; { create: never, link: { name: 'response.hey_Joe',
durable: false, x-declare: { auto-delete: true, exclusive: true, arguments: {
'qpid.max_count': 1000, 'qpid.max_size': 100, 'qpid.policy_type': ring } }
} }
When using python client everything works as expected, but with C++ client
address response/response.hey_Joe is incorrectly translated to
response_response.hey_Joe.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3412) Python and C++ clients translate address differently
[
https://issues.apache.org/jira/browse/QPID-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083056#comment-13083056
]
Gordon Sim commented on QPID-3412:
--
response/response.hey_Joe is *not* translated to response_response.hey_Joe,
what happens is that the name of the node (i.e. the response exchange) is
prefixed to the link name (as specified by the address option) as the resulting
subscription queue name
python by contrast simply uses the link name directly for the queue (which
appears to be the behaviour you expect)
Python and C++ clients translate address differently
Key: QPID-3412
URL: https://issues.apache.org/jira/browse/QPID-3412
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10
Environment: Linux
Reporter: Tomas Soltys
I have a following address string
response/response.hey_Joe; { create: never, link: { name:
'response.hey_Joe', durable: false, x-declare: { auto-delete: true,
exclusive: true, arguments: { 'qpid.max_count': 1000, 'qpid.max_size':
100, 'qpid.policy_type': ring } } } }
When using python client everything works as expected, but with C++ client
address response/response.hey_Joe is incorrectly translated to
response_response.hey_Joe.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3412) Python and C++ clients translate address differently
[
https://issues.apache.org/jira/browse/QPID-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned QPID-3412:
Assignee: Gordon Sim
Python and C++ clients translate address differently
Key: QPID-3412
URL: https://issues.apache.org/jira/browse/QPID-3412
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10
Environment: Linux
Reporter: Tomas Soltys
Assignee: Gordon Sim
I have a following address string
response/response.hey_Joe; { create: never, link: { name:
'response.hey_Joe', durable: false, x-declare: { auto-delete: true,
exclusive: true, arguments: { 'qpid.max_count': 1000, 'qpid.max_size':
100, 'qpid.policy_type': ring } } } }
When using python client everything works as expected, but with C++ client
address response/response.hey_Joe is incorrectly translated to
response_response.hey_Joe.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3413) Plugin Manager Improvements
Plugin Manager Improvements --- Key: QPID-3413 URL: https://issues.apache.org/jira/browse/QPID-3413 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.13 The current PluginManager implementation knows a hardcode list of classes to export as OSGi system packages. This approach makes it difficult for broker plugins authors as they have no means to extend the list. This improvement will extract the list to a separate properties file with the ability to override the properties file in use via System Propery (utilizing the existing FileUtils#openFileOrDefaultResource method). It will also remove the need for PluginManager to be manually editted with each Qpid release. https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3414) Plugin Manager Improvements
Plugin Manager Improvements --- Key: QPID-3414 URL: https://issues.apache.org/jira/browse/QPID-3414 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.13 The current PluginManager implementation knows a hardcode list of classes to export as OSGi system packages. This approach makes it difficult for broker plugins authors as they have no means to extend the list. This improvement will extract the list to a separate properties file with the ability to override the properties file in use via System Propery (utilizing the existing FileUtils#openFileOrDefaultResource method). It will also remove the need for PluginManager to be manually editted with each Qpid release. https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3412) Python and C++ clients translate address differently
[
https://issues.apache.org/jira/browse/QPID-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083082#comment-13083082
]
Gordon Sim commented on QPID-3412:
--
To illustrate the point in previous comment, consider the following address:
my-exchange/my-subject; {link:{name: my-link}}
Here the c++ client would create and bind a queue named my-exchange_my-link,
whereas python would simply use my-link as the subscription queue name. The
rationale for the c++ client behaviour was a desire to provide some logical
grouping between links from the same node. However when the application
controls the name, it can of course do that itself in some way.
Python and C++ clients translate address differently
Key: QPID-3412
URL: https://issues.apache.org/jira/browse/QPID-3412
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10
Environment: Linux
Reporter: Tomas Soltys
Assignee: Gordon Sim
I have a following address string
response/response.hey_Joe; { create: never, link: { name:
'response.hey_Joe', durable: false, x-declare: { auto-delete: true,
exclusive: true, arguments: { 'qpid.max_count': 1000, 'qpid.max_size':
100, 'qpid.policy_type': ring } } } }
When using python client everything works as expected, but with C++ client
address response/response.hey_Joe is incorrectly translated to
response_response.hey_Joe.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3412) Python and C++ clients use link name option differently
[
https://issues.apache.org/jira/browse/QPID-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated QPID-3412:
-
Summary: Python and C++ clients use link name option differently (was:
Python and C++ clients translate address differently)
Python and C++ clients use link name option differently
---
Key: QPID-3412
URL: https://issues.apache.org/jira/browse/QPID-3412
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10
Environment: Linux
Reporter: Tomas Soltys
Assignee: Gordon Sim
I have a following address string
response/response.hey_Joe; { create: never, link: { name:
'response.hey_Joe', durable: false, x-declare: { auto-delete: true,
exclusive: true, arguments: { 'qpid.max_count': 1000, 'qpid.max_size':
100, 'qpid.policy_type': ring } } } }
When using python client everything works as expected, but with C++ client
address response/response.hey_Joe is incorrectly translated to
response_response.hey_Joe.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3414) Plugin Manager Improvements
[ https://issues.apache.org/jira/browse/QPID-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3414: - Description: The current PluginManager implementation knows a hardcode list of classes to export as OSGi system packages. This approach makes it difficult for broker plugins authors as they have no means to extend the list. This improvement will extract the list to a separate properties file with the ability to override the properties file in use via System Propetry (utilizing the existing FileUtils#openFileOrDefaultResource method). It will also remove the need for PluginManager to be manually editted with each Qpid release. https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers was: The current PluginManager implementation knows a hardcode list of classes to export as OSGi system packages. This approach makes it difficult for broker plugins authors as they have no means to extend the list. This improvement will extract the list to a separate properties file with the ability to override the properties file in use via System Propery (utilizing the existing FileUtils#openFileOrDefaultResource method). It will also remove the need for PluginManager to be manually editted with each Qpid release. https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers Plugin Manager Improvements --- Key: QPID-3414 URL: https://issues.apache.org/jira/browse/QPID-3414 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Labels: OSGI Fix For: 0.13 The current PluginManager implementation knows a hardcode list of classes to export as OSGi system packages. This approach makes it difficult for broker plugins authors as they have no means to extend the list. This improvement will extract the list to a separate properties file with the ability to override the properties file in use via System Propetry (utilizing the existing FileUtils#openFileOrDefaultResource method). It will also remove the need for PluginManager to be manually editted with each Qpid release. https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3414) Plugin Manager Improvements
[ https://issues.apache.org/jira/browse/QPID-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083089#comment-13083089 ] Danushka Menikkumbura commented on QPID-3414: - Hi Keith, I strongly believe that the PluginManager should be independent of the OSGi provider. Currently it is Felix-specific. Thanks, Danushka Plugin Manager Improvements --- Key: QPID-3414 URL: https://issues.apache.org/jira/browse/QPID-3414 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Labels: OSGI Fix For: 0.13 The current PluginManager implementation knows a hardcode list of classes to export as OSGi system packages. This approach makes it difficult for broker plugins authors as they have no means to extend the list. This improvement will extract the list to a separate properties file with the ability to override the properties file in use via System Propetry (utilizing the existing FileUtils#openFileOrDefaultResource method). It will also remove the need for PluginManager to be manually editted with each Qpid release. https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r1156604 - in /qpid/trunk/qpid: cpp/src/qpid/broker/SaslAuthenticator.cpp specs/management-schema.xml
On 08/11/2011 01:49 PM, mgoul...@apache.org wrote: Author: mgoulish Date: Thu Aug 11 12:49:39 2011 New Revision: 1156604 URL: http://svn.apache.org/viewvc?rev=1156604view=rev Log: two new management properties for connections: the sasl mechanism, and the ssf (security strength factor).also a change to logging level of one message, so that when we see the list of mechanisms, we will always also see which one was chosen. Modified: qpid/trunk/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp qpid/trunk/qpid/specs/management-schema.xml This breaks the java build. It should also probably have a JIRA associated with it as it is a user visible enhancement. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3412) Python and C++ clients use link name option differently
[
https://issues.apache.org/jira/browse/QPID-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-3412.
--
Resolution: Fixed
Fix Version/s: 0.13
Python and C++ clients use link name option differently
---
Key: QPID-3412
URL: https://issues.apache.org/jira/browse/QPID-3412
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10
Environment: Linux
Reporter: Tomas Soltys
Assignee: Gordon Sim
Fix For: 0.13
I have a following address string
response/response.hey_Joe; { create: never, link: { name:
'response.hey_Joe', durable: false, x-declare: { auto-delete: true,
exclusive: true, arguments: { 'qpid.max_count': 1000, 'qpid.max_size':
100, 'qpid.policy_type': ring } } } }
When using python client everything works as expected, but with C++ client
address response/response.hey_Joe is incorrectly translated to
response_response.hey_Joe.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3415) CRAM-MD5-HASHED not supported by 0-10 protocol (+ no suppport for custom SASL mechanisms).
[
https://issues.apache.org/jira/browse/QPID-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083113#comment-13083113
]
Keith Wall commented on QPID-3415:
--
I'll submit a patch to change the 0-10 code path to use
CallbackHandlerRegistry, whilst retaining support for the sasl_mechs property
and the EXTERNAL/GSSAPI SASL mechanisms.
CRAM-MD5-HASHED not supported by 0-10 protocol (+ no suppport for custom SASL
mechanisms).
--
Key: QPID-3415
URL: https://issues.apache.org/jira/browse/QPID-3415
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.10
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.13
If the Java broker is configured to use the Base64MD5Password password
database the Java client is unable to connect even if they use the sasl_mechs
broker option in the connection URL (sasl_mechs='CRAM-MD5-HASHED').
Instead the user sees:
{code}
org.apache.qpid.AMQException: Cannot connect to broker: Callback handler with
support for AuthorizeCallback required
{code}
The user can work around the problem by passing the -Dqpid.amqp.version
system property to the client, and selecting a protocol 0-10.
The problem is happening because on the 0-10 code path on the client, the
SASL CallbackHandler in use is hardcoded to UsernamePasswordCallbackhandler
(ClientDelegate), rather than using the facilities of CallbackHandlerRegistry
(as does the 0-8 and 0-9* code paths). CRAM-MD5-HASHED requires the use of a
different Callbackhandler.
This also inhibits the use of custom SASL methods by the client.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3415) CRAM-MD5-HASHED not supported by 0-10 protocol (+ no suppport for custom SASL mechanisms).
CRAM-MD5-HASHED not supported by 0-10 protocol (+ no suppport for custom SASL
mechanisms).
--
Key: QPID-3415
URL: https://issues.apache.org/jira/browse/QPID-3415
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.10
Reporter: Keith Wall
Assignee: Keith Wall
Fix For: 0.13
If the Java broker is configured to use the Base64MD5Password password database
the Java client is unable to connect even if they use the sasl_mechs broker
option in the connection URL (sasl_mechs='CRAM-MD5-HASHED').
Instead the user sees:
{code}
org.apache.qpid.AMQException: Cannot connect to broker: Callback handler with
support for AuthorizeCallback required
{code}
The user can work around the problem by passing the -Dqpid.amqp.version system
property to the client, and selecting a protocol 0-10.
The problem is happening because on the 0-10 code path on the client, the SASL
CallbackHandler in use is hardcoded to UsernamePasswordCallbackhandler
(ClientDelegate), rather than using the facilities of CallbackHandlerRegistry
(as does the 0-8 and 0-9* code paths). CRAM-MD5-HASHED requires the use of a
different Callbackhandler.
This also inhibits the use of custom SASL methods by the client.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.12
+1 On 10 August 2011 20:00, Robbie Gemmell robbie.gemm...@gmail.com wrote: +1 I have staged the Maven artifacts for the Java client on the ASF Nexus instance and tested them, they can be promoted upon distribution of the release (which as previously should not include the maven directory output by the release script) by logging into Nexus at https://repository.apache.org/ They are temporarily available at the following URL should anyone else wish to test them: https://repository.apache.org/content/repositories/orgapacheqpid-016/ Robbie On 9 August 2011 20:35, Justin Ross jr...@redhat.com wrote: Howdy, all. The last-minute blocker, QPID-3394, has been fixed, and there are no open blocker jiras against 0.12. The proposed final RC, from revision 1154981 of the 0.12 release branch, is available here: http://people.apache.org/~jross/qpid-0.12/ If you favor releasing this distribution as Qpid 0.12, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. If the release proceeds, I'll take the final steps to publicize and distribute the release. That should take one or two days. --- 0.12 release page: https://cwiki.apache.org/qpid/012-release.html - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
IPv6 support for Java for 0.14?
I've been spending much of my time in the past few weeks getting support for IPv6 in to the C++ and python code bases, and I expect to get it in the code base in the next few days (unless someone can see a problem not yet noticed with the code). I've created an umbrella Jira - QPID-3404 to track IPv6 work with a bunch of sub-tasks to track the details. It'd be great if we can announce full IPv6 support for the 0.14 release: Does anyone more qualified than me want to take on the work for the Java code base? I'd be happy to advise or even do the work if no one else steps forward, but I suspect that someone more familiar with the Java code would be better suited. So I'm really appealing for volunteers for QPID-3408 - https://issues.apache.org/jira/browse/QPID-3408 Note that in general there are two issues in IPv6 support that have emerged so far: 1. Actually listening/connecting to IPv6 sockets (including the correct reconnect and multiple listening socket logic) 2. Adding literal IPv6 support to any URL parsing. They are separable and 1 is useful without 2, but 2 is necessary to have complete IPv6 support. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IPv6 support for Java for 0.14?
On Thu, Aug 11, 2011 at 10:59 AM, Andrew Stitcher astitc...@redhat.com wrote: I've been spending much of my time in the past few weeks getting support for IPv6 in to the C++ and python code bases, and I expect to get it in the code base in the next few days (unless someone can see a problem not yet noticed with the code). I've created an umbrella Jira - QPID-3404 to track IPv6 work with a bunch of sub-tasks to track the details. It'd be great if we can announce full IPv6 support for the 0.14 release: Does anyone more qualified than me want to take on the work for the Java code base? I'd be happy to advise or even do the work if no one else steps forward, but I suspect that someone more familiar with the Java code would be better suited. So I'm really appealing for volunteers for QPID-3408 - https://issues.apache.org/jira/browse/QPID-3408 Note that in general there are two issues in IPv6 support that have emerged so far: 1. Actually listening/connecting to IPv6 sockets (including the correct reconnect and multiple listening socket logic) My understanding is that since Java 1.4, there have been support for IPv6. AFAIK this is transparent and code wise we don't really have to do anything special. But of course we have to test this out and see. 2. Adding literal IPv6 support to any URL parsing. This is where I suspect we will need some work. The URL parser **may** fail when we use a IPv6 address. If it does not, then that would be a real bonus. I will test this out today and see. They are separable and 1 is useful without 2, but 2 is necessary to have complete IPv6 support. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IPv6 support for Java for 0.14?
On Thu, 2011-08-11 at 12:27 -0400, Andrew Stitcher wrote: On Thu, 2011-08-11 at 11:08 -0400, Rajith Attapattu wrote: ... 1. Actually listening/connecting to IPv6 sockets (including the correct reconnect and multiple listening socket logic) My understanding is that since Java 1.4, there have been support for IPv6. AFAIK this is transparent and code wise we don't really have to do anything special. But of course we have to test this out and see. I doubt this is the case unless thought has gone into it initially, as you have to do things differently to get v6 sockets as opposed to v4. I'll go and look at code to see if I can substantiate. I retract that. From what I can see in the code it looks like IPv6 addresses will get correctly resolved and connected to. However I'm couldn't see anywhere which would do the correct retry logic if say the first resolved address wasn't available. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IPv6 support for Java for 0.14?
On Thu, 2011-08-11 at 11:08 -0400, Rajith Attapattu wrote: ... 1. Actually listening/connecting to IPv6 sockets (including the correct reconnect and multiple listening socket logic) My understanding is that since Java 1.4, there have been support for IPv6. AFAIK this is transparent and code wise we don't really have to do anything special. But of course we have to test this out and see. I doubt this is the case unless thought has gone into it initially, as you have to do things differently to get v6 sockets as opposed to v4. I'll go and look at code to see if I can substantiate. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IPv6 support for Java for 0.14?
On 08/11/2011 06:40 PM, Andrew Stitcher wrote: On Thu, 2011-08-11 at 12:27 -0400, Andrew Stitcher wrote: On Thu, 2011-08-11 at 11:08 -0400, Rajith Attapattu wrote: ... 1. Actually listening/connecting to IPv6 sockets (including the correct reconnect and multiple listening socket logic) My understanding is that since Java 1.4, there have been support for IPv6. AFAIK this is transparent and code wise we don't really have to do anything special. But of course we have to test this out and see. I doubt this is the case unless thought has gone into it initially, as you have to do things differently to get v6 sockets as opposed to v4. I'll go and look at code to see if I can substantiate. I retract that. From what I can see in the code it looks like IPv6 addresses will get correctly resolved and connected to. However I'm couldn't see anywhere which would do the correct retry logic if say the first resolved address wasn't available. http://download.oracle.com/javase/1.5.0/docs/guide/net/ipv6_guide/index.html Which claims: With Java you can run any Java applications, client or server, on an IPv6-enabled platform using J2SE 1.4 or later, and that application will automagically become IPv6-enabled. It also states: that on a dual-stack machine, since one socket, the IPv6 socket, will be able to access both IPv4 and IPv6 protocol stacks, you only need to create one socket does this mean on Linux we don't need to create multiple sockets to listen on? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
0.14 release update - schedule
While Qpid 0.12 is still hanging out for a few more votes, I thought I'd send out a pointer to our 0.14 release page. https://cwiki.apache.org/qpid/014-release.html There's not much there yet apart from the proposed schedule. Over time this page will host more content. 0.14 itself has been underway since the end of June. It is scheduled to freeze (for disruptive changes) on October 19th and release at the end of November. Thanks, Justin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: IPv6 support for Java for 0.14?
On Thu, 2011-08-11 at 20:10 +0100, Gordon Sim wrote: http://download.oracle.com/javase/1.5.0/docs/guide/net/ipv6_guide/index.html Which claims: With Java you can run any Java applications, client or server, on an IPv6-enabled platform using J2SE 1.4 or later, and that application will automagically become IPv6-enabled. It also states: that on a dual-stack machine, since one socket, the IPv6 socket, will be able to access both IPv4 and IPv6 protocol stacks, you only need to create one socket does this mean on Linux we don't need to create multiple sockets to listen on? That is correct, you can use an IPv6 socket to accept IPv4 connections too, but there are good reasons you might want to create separate v4 and v6 only listening sockets. Essentially this gives you stronger control over the protocols individually if you need that, although this rationale in c/c++ might not fully exist in Java - I don't understand the details there fully. In order to do this with a single socket though it needs to be a v6 socket. Reading that doc briefly it looks like the reconnect logic might be transparent to the application which would be nice and explain why I didn't see it anywhere. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.12
+1 On 08/09/2011 03:35 PM, Justin Ross wrote: Howdy, all. The last-minute blocker, QPID-3394, has been fixed, and there are no open blocker jiras against 0.12. The proposed final RC, from revision 1154981 of the 0.12 release branch, is available here: http://people.apache.org/~jross/qpid-0.12/ If you favor releasing this distribution as Qpid 0.12, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. If the release proceeds, I'll take the final steps to publicize and distribute the release. That should take one or two days. --- 0.12 release page: https://cwiki.apache.org/qpid/012-release.html - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-2057) qpidd --require-encryption forces SASL security layer to be used even if SSL is in use
[ https://issues.apache.org/jira/browse/QPID-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-2057: -- Fix Version/s: (was: 0.11) Future qpidd --require-encryption forces SASL security layer to be used even if SSL is in use -- Key: QPID-2057 URL: https://issues.apache.org/jira/browse/QPID-2057 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Ted Ross Assignee: michael j. goulish Priority: Minor Fix For: Future If running SSL and using GSSAPI authentication with the --require-encryption option turned on, the SASL layer will force minSsf to be greater than zero, thus causing the SASL security layer to encrypt. This is unnecessary double-encryption since SSL is already providing a cipher channel at a lower layer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-2316) 0.6RC2 C++ Build fails if ruby-dev and swig installed
[ https://issues.apache.org/jira/browse/QPID-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083552#comment-13083552 ] Justin Ross commented on QPID-2316: --- Can we declare this issue resolved? 0.6RC2 C++ Build fails if ruby-dev and swig installed - Key: QPID-2316 URL: https://issues.apache.org/jira/browse/QPID-2316 Project: Qpid Issue Type: Bug Components: Build Tools Affects Versions: 0.6, 0.7 Reporter: Rob Godfrey Assignee: Ted Ross Fix For: 0.11 When attempting to build the C++ contained in the artefact at http://qpid.apache.org/dist/qpid-0.6rc2/qpid-0.6rc2.tar.gz I got the following error on my machine: Making all in ruby make[2]: Entering directory `/home/rob/qpidc-0.6/bindings/qmf/ruby' make[2]: *** No rule to make target `ruby.i', needed by `qmfengine.cpp'. Stop. Further investigation showed that the build succeeded on a separate machine, however on this machine the qmfengine.cpp target was commented out in the buildfile. This was as a result of the fact that the second machine did not have ruby development and SWIG packages installed. After installing these packages the second machine failed in the same way as the first -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-2993) Federated source-local links crash remotely federated cluster member on local cluster startup
[ https://issues.apache.org/jira/browse/QPID-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-2993: -- Fix Version/s: (was: 0.11) Future Federated source-local links crash remotely federated cluster member on local cluster startup - Key: QPID-2993 URL: https://issues.apache.org/jira/browse/QPID-2993 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: 0.8 Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4 Reporter: Mark Moseley Assignee: michael j. goulish Fix For: Future Attachments: 2993_bug.sh, cluster-fed-src.sh This is related to JIRA 2992 that I opened, but this is for source-local routes. Given the same setup as in JIRA 2992 but using source-local routes (and obviously with the exchanges switched accordingly in the qpid-route statements), i.e. cluster A and cluster B with the routes between A1-B1, when cluster B shuts down in the order B2-B1 and starts back up, the static routes are not correctly re-bound on cluster A's side. However if cluster B is shut down in the order B1-B2 and started back up, the route is correctly created and works. However in the non-functioning case (B2-B1, or A2-A1), there is an additional side-effect: on node A2, qpidd crashes with the following error (cluster A is called 'walclust', B is bosclust): 2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error 2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) 2011-01-07 18:57:35 critical Error delivering frames: local error did not occur on all cluster members : not-attached: Channel 1 is not attached (qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89) 2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving cluster walclust 2011-01-07 18:57:35 notice Shut down This happens on both sides of the cluster, so it's not limited to one or the other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test where the route is re-bound correctly). I can cause this to reoccur pretty much every time. I've been resetting the cluster completely to a new state between each test. Occasionally in the B2-B1 test, A1 will also crash with the same error (and vice versa for A2-A1 for node B1), though most of the time, it's A2/B2 that crashes. I was getting this same behaviour prior to upgrading corosync/openais as well. Previously I was using the stock Squeeze versions of corosync==1.2.1 and openais==1.1.2. The results are the same with corosync=1.3.0 and openais==1.1.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3061) Discrepancies between CMake and Automake
[ https://issues.apache.org/jira/browse/QPID-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-3061: -- Fix Version/s: (was: 0.11) Future Discrepancies between CMake and Automake Key: QPID-3061 URL: https://issues.apache.org/jira/browse/QPID-3061 Project: Qpid Issue Type: Bug Components: Build Tools Affects Versions: 0.8 Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: Future There are some changes that were put into Autoconf/Automake but not Cmake. This issue is for tracking the synchronization of cmake to automake. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3066) UTF8Test does not run under non VM 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083559#comment-13083559 ] Justin Ross commented on QPID-3066: --- This looks like it may be resolved. True? UTF8Test does not run under non VM 0-10 profiles Key: QPID-3066 URL: https://issues.apache.org/jira/browse/QPID-3066 Project: Qpid Issue Type: Bug Components: Java Tests Affects Versions: 0.9 Reporter: Andrew Kennedy Assignee: Andrew Kennedy Priority: Minor Fix For: 0.11 The UTF8Test uses the 'isBrokerExternal' and 'isBroker010' methods to check whether it should run, rather than relying on the Excludes files. The checks wrongly cause an exception to be thrown on the java.0.10 test profile. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3111) DynamicQueueExchangeCreateTest should check for 404 error code explicitly
[ https://issues.apache.org/jira/browse/QPID-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083673#comment-13083673 ] Justin Ross commented on QPID-3111: --- Is this issue fixed? DynamicQueueExchangeCreateTest should check for 404 error code explicitly - Key: QPID-3111 URL: https://issues.apache.org/jira/browse/QPID-3111 Project: Qpid Issue Type: Bug Components: Java Tests Affects Versions: 0.9 Reporter: Andrew Kennedy Assignee: Andrew Kennedy Priority: Minor Fix For: 0.11 DynamicQueueExchangeCreateTest checks for a tect string in the message property of a thrown exception. This is brittle and should be replaced with a check for the AMQConstant#NOT_FOUND (404) error code instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.12
+1 -K - Original Message - Howdy, all. The last-minute blocker, QPID-3394, has been fixed, and there are no open blocker jiras against 0.12. The proposed final RC, from revision 1154981 of the 0.12 release branch, is available here: http://people.apache.org/~jross/qpid-0.12/ If you favor releasing this distribution as Qpid 0.12, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. If the release proceeds, I'll take the final steps to publicize and distribute the release. That should take one or two days. --- 0.12 release page: https://cwiki.apache.org/qpid/012-release.html - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[QUESTION] Concerning JIRA QPID-2549
Hi, I created a FreeBSD port of Qpid 0.10 but am stuck at the issue described in #QPID-2549 [1]. Just to understand it completely - does the JIRA mean Qpid is completely broken on FreeBSD or would it be possible to navigate around the Poller related error messages by specifying --without-poller while configuring Qpid? PS: I intend to create the Qpid FreeBSD in support of creating an Apache Tuscany FreeBSD port which has an optional dependency on Apache Qpid. [1] https://issues.apache.org/jira/browse/QPID-2549 Thanks and best wishes! Cheers Daniel - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
