Re: Binding URL Options
Hi Rajith, Option reject_behaviour was introduced as part of work on implementing DLQ functionality in java broker. This is only 0-9-1 client setting and it is not needed for 0-10 client. By default, redelivered messages are not moved into DLQ after exceeding Maximum redelivery attempts (for backward compatibility). In order to have redelivered messages to be moved into DLQ after reaching Maximum redelivery number the client should set reject_behaviour=server either as a connection option or a queue Binding URL option. Kind Regards, Alex On 14 May 2012 22:36, Rajith Attapattu rajit...@gmail.com wrote: Hi All, I'm trying to compile an exhaustive list of all the valid options for binding URL. Some of the options make sense while others a lot is left to be desired. I'd really appreciate some help in agreeing to a proper list and also updating the wiki for accuracy. The wiki page here https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the following options. exclusive boolean Is this an exclusive connection autodelete boolean Should this queue be deleted on client disconnection durable boolean Create a durable queue clientid string Use the following client id subscription boolean Create a subscription to this destination routingkey string Use this value as the routing key While the code has the following options, public static final String OPTION_EXCLUSIVE = exclusive; public static final String OPTION_AUTODELETE = autodelete; public static final String OPTION_DURABLE = durable; public static final String OPTION_BROWSE = browse; public static final String OPTION_CLIENTID = clientid; public static final String OPTION_SUBSCRIPTION = subscription; public static final String OPTION_ROUTING_KEY = routingkey; public static final String OPTION_BINDING_KEY = bindingkey; public static final String OPTION_REJECT_BEHAVIOUR = rejectbehaviour; (*) Multiple Binding keys can be specified. While most of the options are quite straight forward I'm trying to figure out the intended behaviour for a few. 1. Subscription What's the intended usage for subscription ? All though the wiki lists it as a boolean it has been used in a rather bizarre way in the BindingURLParser.java (All though I was the author of BindingURLParser I simply used the same that was there in the old code). Could we remove this option? 2. Client ID We don't use the queue-name worked out here in anyway when we create the durable subscription name. Could we remove this option ? 3. OPTION_REJECT_BEHAVIOUR Could somebody please explain the intended behaviour for this option so I could correctly pass it when creating the address structure out of a BURL. Regards, Rajith - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Qpid Enquiry
Hello, I have installed qpid package with c++ broker under windows environment. I already developed qpid application for my project, my customers have been using my apps for 2 years without problem. I am having more potential and bigger customers in near future. They require that my system need to configure SSL security to transmit/receive data over secured network. Any user is familiar with setting up QPID SSL under windows environment before? Can any user help me to explain in stepwise how to configure? I heard this is possible to be done under windows. Please note that we are not developing this app under linux environment. Thank you very much in advance. Regards, Willy Software Engineer Asia
RE: Qpid Enquiry
Hi Wielly,
Thank you for your patience. Cliff Jansen recently posted the attached
steps for setting up SSL on Windows.
-Steve
-Original Message-
From: Wielly [mailto:wie...@weikegaming.com]
Sent: Tuesday, May 15, 2012 4:53 AM
To: dev@qpid.apache.org
Subject: Qpid Enquiry
Hello,
I have installed qpid package with c++ broker under windows environment.
I
already developed qpid application for my project, my customers have
been
using my apps for 2 years without problem.
I am having more potential and bigger customers in near future. They
require
that my system need to configure SSL security to transmit/receive data
over
secured network.
Any user is familiar with setting up QPID SSL under windows
environment
before? Can any user help me to explain in stepwise how to configure? I
heard this is possible to be done under windows.
Please note that we are not developing this app under linux environment.
Thank you very much in advance.
Regards,
Willy
Software Engineer Asia
---BeginMessage---
Here is a recipe for using the tools you are used to on Linux and
interoperating with Windows. Hopefully you can find the info you are
looking for buried inside.
For general info, see qpid/cpp/SSL and note in particular that the
current Qpid implementation is Registry based. Type qpidd --help
for ssl specific args.
I tried to avoid the GUI on Windows but failed, sorry. I was also
unable to find any way to create a new certificate store without the
hack of creating a sacrificial self signed cert first.
notused.example.com is that sacrificial cert.
I had to run mmc, makecert, and qpidd as an administrator. I could
run qpid-perftest without exalted privilege.
I used two separate stores on Linux, but that wasn't necessary.
CASE 1: Windows client + Linux broker (linux1.example.com)
[ on Linux ]
$ pwd
/b/amqp/b/q16b9/ssltest/l
$ export QPID_SSL_CERT_PASSWORD_FILE=`pwd`/pwf
$ export QPID_SSL_CERT_DB=`pwd`/db
$ export QPID_SSL_CERT_NAME=linux1.example.com
$ echo secret pwf
$ mkdir db
$ certutil -N -d ${QPID_SSL_CERT_DB} -f ${QPID_SSL_CERT_PASSWORD_FILE}
$ certutil -S -d ${QPID_SSL_CERT_DB} -n ${QPID_SSL_CERT_NAME} -s
CN=${QPID_SSL_CERT_NAME} -t CT,, -x -f ${QPID_SSL_CERT_PASSWORD_FILE} -v
36
[ entropy stuff ... ]
$
$ /b/amqp/b/q16b9/rt/sbin/qpidd --auth no -p 18641 --ssl-cert-password-file
$QPID_SSL_CERT_PASSWORD_FILE --ssl-cert-name $QPID_SSL_CERT_NAME --ssl-port
18642 --ssl-cert-db $QPID_SSL_CERT_DB --module-dir
/b/amqp/b/q16b9/rt/lib/qpid/daemon
[1] 20016
$
[export cert]
$ certutil -L -d ${QPID_SSL_CERT_DB} -n ${QPID_SSL_CERT_NAME} -f
${QPID_SSL_CERT_PASSWORD_FILE} -a /tmp/linux1.pub.cer
[ on Windows ]
mmc [run as administrator]
File-snap-in-Certificates-add
Computer account [not User or Service] - Local computer
Certificates- Trusted Root CAs - right click - all tasks - Import...
[in wizard] - browse to linux1.pub.cer - open - finish
PS C:\cj\work\amqp\wcf\q1701\bin .\qpid-perftest.exe -b
linux1.example.com -p 5672 -P ssl --count 1 --summary
CASE 2: Windows broker (win1.example.com) + Linux client
$ mkdir db
$ echo secret pwf
$ export QPID_SSL_CERT_PASSWORD_FILE=`pwd`/pwf
$ export QPID_SSL_CERT_DB=`pwd`/db
$ pwd
/b/amqp/b/q16b9/ssltest/w
$
$ certutil -N -d ${QPID_SSL_CERT_DB} -f ${QPID_SSL_CERT_PASSWORD_FILE}
$
$ export QPID_SSL_CERT_NAME=win1.example.com
$ certutil -S -d ${QPID_SSL_CERT_DB} -n ${QPID_SSL_CERT_NAME} -s
CN=${QPID_SSL_CERT_NAME} -t CT,, -x -f ${QPID_SSL_CERT_PASSWORD_FILE} -v
36
[entropy stuff]
[ this time need to export private key too, so use pk12util ]
$ pk12util -o win1.p12 -n ${QPID_SSL_CERT_NAME} -d ${QPID_SSL_CERT_DB}
Enter Password or Pin for NSS Certificate DB:secret
Enter password for PKCS12 file: very_secret
Re-enter password: very_secret
pk12util: PKCS12 EXPORT SUCCESSFUL
$
[ on Windows ]
[ hack to create qpidtest certificate store ]
cd C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin
makecert -ss qpidtest -n CN=notused.example.com -r -sr localmachine
notused.cer
[ import the cert for win1.example.com ]
same mmc GUI steps except
right click from qpidtest store you just created
browse to win1.p12 and select file type PKCS#12 if it is not listed
PS C:\cj\work\amqp\wcf\q1701\bin .\qpidd.exe --auth
no --no-data-dir --ssl-cert-store qpidtest --ssl-cert-name win1.example.com
[ back on Linux ]
$ export QPID_LOAD_MODULE=/b/amqp/b/q16b9/rt/lib/qpid/client/sslconnector.so
$ env | grep QPID
QPID_LOAD_MODULE=/b/amqp/b/q16b9/rt/lib/qpid/client/sslconnector.so
QPID_SSL_CERT_DB=/b/amqp/b/q16b9/ssltest/w/db
QPID_SSL_CERT_NAME=win1.example.com
QPID_SSL_CERT_PASSWORD_FILE=/b/amqp/b/q16b9/ssltest/w/pwf
$ /b/amqp/b/q16b9/rt/libexec/qpid/tests/qpid-perftest -p 5671 --count
1 -P ssl --summary -b win1.example.com
464.89 452.492 918.965 0.897427
$
- Original Message -
From: Andrew Stitcher astitc...@redhat.com
To: Qpid Dev List dev@qpid.apache.org, Steve Huston
Re: Binding URL Options
Alex, Thanks for the explanation. I assume this is passed as a queue-declare argument ? Regards, Rajith On Tue, May 15, 2012 at 4:30 AM, Oleksandr Rudyy oru...@gmail.com wrote: Hi Rajith, Option reject_behaviour was introduced as part of work on implementing DLQ functionality in java broker. This is only 0-9-1 client setting and it is not needed for 0-10 client. By default, redelivered messages are not moved into DLQ after exceeding Maximum redelivery attempts (for backward compatibility). In order to have redelivered messages to be moved into DLQ after reaching Maximum redelivery number the client should set reject_behaviour=server either as a connection option or a queue Binding URL option. Kind Regards, Alex On 14 May 2012 22:36, Rajith Attapattu rajit...@gmail.com wrote: Hi All, I'm trying to compile an exhaustive list of all the valid options for binding URL. Some of the options make sense while others a lot is left to be desired. I'd really appreciate some help in agreeing to a proper list and also updating the wiki for accuracy. The wiki page here https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the following options. exclusive boolean Is this an exclusive connection autodelete boolean Should this queue be deleted on client disconnection durable boolean Create a durable queue clientid string Use the following client id subscription boolean Create a subscription to this destination routingkey string Use this value as the routing key While the code has the following options, public static final String OPTION_EXCLUSIVE = exclusive; public static final String OPTION_AUTODELETE = autodelete; public static final String OPTION_DURABLE = durable; public static final String OPTION_BROWSE = browse; public static final String OPTION_CLIENTID = clientid; public static final String OPTION_SUBSCRIPTION = subscription; public static final String OPTION_ROUTING_KEY = routingkey; public static final String OPTION_BINDING_KEY = bindingkey; public static final String OPTION_REJECT_BEHAVIOUR = rejectbehaviour; (*) Multiple Binding keys can be specified. While most of the options are quite straight forward I'm trying to figure out the intended behaviour for a few. 1. Subscription What's the intended usage for subscription ? All though the wiki lists it as a boolean it has been used in a rather bizarre way in the BindingURLParser.java (All though I was the author of BindingURLParser I simply used the same that was there in the old code). Could we remove this option? 2. Client ID We don't use the queue-name worked out here in anyway when we create the durable subscription name. Could we remove this option ? 3. OPTION_REJECT_BEHAVIOUR Could somebody please explain the intended behaviour for this option so I could correctly pass it when creating the address structure out of a BURL. Regards, Rajith - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: Limit number of queues a user can create
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5015/ --- (Updated 2012-05-15 13:41:01.807339) Review request for qpid, Alan Conway, Kim van der Riet, and Ted Ross. Changes --- 1. User name against whom quotas are taken is stored in queue.settings so that it persists in store and across replication. 2. Queue provides user name accessor methods for QueueRegistry. 3. Queue limits exceed by 'recovered' events are allowed. There's no proper mechanism to dispose/disallow creation of these queues and doing so would result in data loss and other issues. 4. This is untested against a store or cluster replication but is ready to go for either. Summary --- This patch fulfills a long-standing request to keep users from abusing broker queue resources. If a user is allowed to create one queue he then can create them by the thousdands. The code is more of a quota than an access control but it fits naturally in the current ACL module. The implementation here is queue-centric but could be generalized to support limiting exchanges as well. A few concerns arise: 1. This code counts/protects live requests coming in to single node. This code does not protect queues that are presisting. The concern is that a user creates his quota of persistent queues and then upon system restart the same user can create another batch of queues since the persisted queues aren't tracked. Is this a vaild concern? 2. The patch provides only a single setting for all users. 3. The patch makes no effort to replicate the queue count state across a cluster. Surely this is a problem for clusters. This addresses bug QPID-2393. https://issues.apache.org/jira/browse/QPID-2393 Diffs (updated) - trunk/qpid/cpp/src/qpid/acl/Acl.h 1336822 trunk/qpid/cpp/src/qpid/acl/Acl.cpp 1336822 trunk/qpid/cpp/src/qpid/acl/AclPlugin.cpp 1336822 trunk/qpid/cpp/src/qpid/acl/management-schema.xml 1336822 trunk/qpid/cpp/src/qpid/broker/AclModule.h 1336822 trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1336822 trunk/qpid/cpp/src/qpid/broker/Queue.h 1336822 trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1336822 trunk/qpid/cpp/src/qpid/broker/QueueRegistry.h 1336822 trunk/qpid/cpp/src/qpid/broker/QueueRegistry.cpp 1336822 trunk/qpid/cpp/src/tests/acl.py 1336822 trunk/qpid/cpp/src/tests/run_acl_tests 1336822 Diff: https://reviews.apache.org/r/5015/diff Testing --- Unit tests included. Thanks, Chug
[jira] [Commented] (QPID-2393) Qpid C++ broker: request for feature to limit number of queues per user
[ https://issues.apache.org/jira/browse/QPID-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13275781#comment-13275781 ] jirapos...@reviews.apache.org commented on QPID-2393: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5015/ --- (Updated 2012-05-15 13:41:01.807339) Review request for qpid, Alan Conway, Kim van der Riet, and Ted Ross. Changes --- 1. User name against whom quotas are taken is stored in queue.settings so that it persists in store and across replication. 2. Queue provides user name accessor methods for QueueRegistry. 3. Queue limits exceed by 'recovered' events are allowed. There's no proper mechanism to dispose/disallow creation of these queues and doing so would result in data loss and other issues. 4. This is untested against a store or cluster replication but is ready to go for either. Summary --- This patch fulfills a long-standing request to keep users from abusing broker queue resources. If a user is allowed to create one queue he then can create them by the thousdands. The code is more of a quota than an access control but it fits naturally in the current ACL module. The implementation here is queue-centric but could be generalized to support limiting exchanges as well. A few concerns arise: 1. This code counts/protects live requests coming in to single node. This code does not protect queues that are presisting. The concern is that a user creates his quota of persistent queues and then upon system restart the same user can create another batch of queues since the persisted queues aren't tracked. Is this a vaild concern? 2. The patch provides only a single setting for all users. 3. The patch makes no effort to replicate the queue count state across a cluster. Surely this is a problem for clusters. This addresses bug QPID-2393. https://issues.apache.org/jira/browse/QPID-2393 Diffs (updated) - trunk/qpid/cpp/src/qpid/acl/Acl.h 1336822 trunk/qpid/cpp/src/qpid/acl/Acl.cpp 1336822 trunk/qpid/cpp/src/qpid/acl/AclPlugin.cpp 1336822 trunk/qpid/cpp/src/qpid/acl/management-schema.xml 1336822 trunk/qpid/cpp/src/qpid/broker/AclModule.h 1336822 trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1336822 trunk/qpid/cpp/src/qpid/broker/Queue.h 1336822 trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1336822 trunk/qpid/cpp/src/qpid/broker/QueueRegistry.h 1336822 trunk/qpid/cpp/src/qpid/broker/QueueRegistry.cpp 1336822 trunk/qpid/cpp/src/tests/acl.py 1336822 trunk/qpid/cpp/src/tests/run_acl_tests 1336822 Diff: https://reviews.apache.org/r/5015/diff Testing --- Unit tests included. Thanks, Chug Qpid C++ broker: request for feature to limit number of queues per user --- Key: QPID-2393 URL: https://issues.apache.org/jira/browse/QPID-2393 Project: Qpid Issue Type: Improvement Components: C++ Broker Environment: Red Hat Enterprise MRG 1.2 Reporter: Armin Noll Assignee: Chuck Rolke With issue QPID-2108 (Red Hat service request #1950278) a new feature has been introduced which allows to control via ACL the size of queues and their limit policy on user level. The original request contained also the requirement to gain control over the number of queues a user may create. ACL should be enhanced to allow specifying a maximum number of queues for a single user. Altogether these features shall enable the operator of a Qpid broker to keep better control over the resources. We will prepare a draft implementation and provide it asap. This request has also been reported as Red Hat service request #1992776. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release 0.16
+1 Carl. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-3209) Allow variables like authenticated username in ACL rules
[
https://issues.apache.org/jira/browse/QPID-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned QPID-3209:
Assignee: Ken Giusti
Allow variables like authenticated username in ACL rules
Key: QPID-3209
URL: https://issues.apache.org/jira/browse/QPID-3209
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Reporter: Jonas Klemming
Assignee: Ken Giusti
Priority: Minor
It would be very useful to allow rules to contain variables like
authenticated username.
One usecase is when you need to create a separate queue for each user.
Instead of creating lots of rules you could just write:
acl allow ${username} all queue name=myqueue.${username}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-3209) Allow variables like authenticated username in ACL rules
[
https://issues.apache.org/jira/browse/QPID-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti reassigned QPID-3209:
Assignee: (was: Ken Giusti)
Allow variables like authenticated username in ACL rules
Key: QPID-3209
URL: https://issues.apache.org/jira/browse/QPID-3209
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Reporter: Jonas Klemming
Priority: Minor
It would be very useful to allow rules to contain variables like
authenticated username.
One usecase is when you need to create a separate queue for each user.
Instead of creating lots of rules you could just write:
acl allow ${username} all queue name=myqueue.${username}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-3996) [Java Broker] Update optional BDB dependency to use latest version
Rob Godfrey created QPID-3996: - Summary: [Java Broker] Update optional BDB dependency to use latest version Key: QPID-3996 URL: https://issues.apache.org/jira/browse/QPID-3996 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Broker BDB Store Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 Update dependency to latest version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-3996) [Java Broker] Update optional BDB dependency to use latest version
[ https://issues.apache.org/jira/browse/QPID-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved QPID-3996. --- Resolution: Fixed [Java Broker] Update optional BDB dependency to use latest version -- Key: QPID-3996 URL: https://issues.apache.org/jira/browse/QPID-3996 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Broker BDB Store Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 Update dependency to latest version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-3997) [Java Broker] Allow assignment of AuthenticationManager on a per-port basis
Rob Godfrey created QPID-3997: - Summary: [Java Broker] Allow assignment of AuthenticationManager on a per-port basis Key: QPID-3997 URL: https://issues.apache.org/jira/browse/QPID-3997 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Currently we only allow for a single AuthenticationManager across all ports. We should allow for separate ports to allow for different authentication schemes. Ideally we should also allow for different vhosts to be bound to different ports and for different SASL mechanisms to be bound to different authentication managers, but these steps should be covered by later JIRAs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4000) [Java 1.0] Implement message translation between AMQP 1.0 and other AMQP message types
Rob Godfrey created QPID-4000: - Summary: [Java 1.0] Implement message translation between AMQP 1.0 and other AMQP message types Key: QPID-4000 URL: https://issues.apache.org/jira/browse/QPID-4000 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 Allow automatic conversion between AMQP 1.0 messages and 0-8,0-9,0-10 messages within the broker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-3999) [Java Broker] Implement Web based management tool for the Java Broker
Rob Godfrey created QPID-3999: - Summary: [Java Broker] Implement Web based management tool for the Java Broker Key: QPID-3999 URL: https://issues.apache.org/jira/browse/QPID-3999 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Fix For: 0.17 Implement a web front end which uses the RESTful HTTP management API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [Created] (QPID-4000)
Well played...I was planning to do that as well at some point this week ;) Robbie -- Forwarded message -- From: Rob Godfrey (JIRA) j...@apache.org Date: 15 May 2012 21:49 Subject: [jira] [Created] (QPID-4000) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4001) Add a java version of the Qpid API
Rajith Attapattu created QPID-4001: -- Summary: Add a java version of the Qpid API Key: QPID-4001 URL: https://issues.apache.org/jira/browse/QPID-4001 Project: Qpid Issue Type: New Feature Components: Java Client Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.17 Both C++ and Python have a common API that is commonly referred to as the Qpid API. There have been numerous requests to add one for Java. The consensus we have so far for the upcomming new client is to have the following layering where the Qpid API is a major component. proton-j -- Qpid API -- JMS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3996) [Java Broker] Update optional BDB dependency to use latest version
[ https://issues.apache.org/jira/browse/QPID-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276253#comment-13276253 ] Rajith Attapattu commented on QPID-3996: As the first step we should agree on how the Qpid API in java should like. while a lot of it is going to be determined by the already available versions for python and C++, there will still be a few slight differences to conform to the java idioms. [Java Broker] Update optional BDB dependency to use latest version -- Key: QPID-3996 URL: https://issues.apache.org/jira/browse/QPID-3996 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Broker BDB Store Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 Update dependency to latest version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [Created] (QPID-4000)
I just lost by a few mins :( ... damn it. Rajith On Tue, May 15, 2012 at 5:52 PM, Rob Godfrey rob.j.godf...@gmail.comwrote: QPID-1000 : Martin Ritchie QPID-2000 : Robbie Gemmel QPID-3000 : Gordon Sim QPID-4000 : Robert Godfrey 4-0 to the Brits so far in the grabbing meaningless trophy JIRA numbers competition :-) -- Rob On 15 May 2012 23:31, Robbie Gemmell robbie.gemm...@gmail.com wrote: Well played...I was planning to do that as well at some point this week ;) Robbie -- Forwarded message -- From: Rob Godfrey (JIRA) j...@apache.org Date: 15 May 2012 21:49 Subject: [jira] [Created] (QPID-4000) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Binding URL Options
No, it is used client side in the 0-8/0-9/0-9-1 session/consumer code to influence its rejection behaviour. If you follow the use of the constant I'm sure you will run into it fairly quickly. I'm not sure how used (if at all) the other two options you singled out are, but this one is. Robbie On 15 May 2012 14:24, Rajith Attapattu rajit...@gmail.com wrote: Alex, Thanks for the explanation. I assume this is passed as a queue-declare argument ? Regards, Rajith On Tue, May 15, 2012 at 4:30 AM, Oleksandr Rudyy oru...@gmail.com wrote: Hi Rajith, Option reject_behaviour was introduced as part of work on implementing DLQ functionality in java broker. This is only 0-9-1 client setting and it is not needed for 0-10 client. By default, redelivered messages are not moved into DLQ after exceeding Maximum redelivery attempts (for backward compatibility). In order to have redelivered messages to be moved into DLQ after reaching Maximum redelivery number the client should set reject_behaviour=server either as a connection option or a queue Binding URL option. Kind Regards, Alex On 14 May 2012 22:36, Rajith Attapattu rajit...@gmail.com wrote: Hi All, I'm trying to compile an exhaustive list of all the valid options for binding URL. Some of the options make sense while others a lot is left to be desired. I'd really appreciate some help in agreeing to a proper list and also updating the wiki for accuracy. The wiki page here https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the following options. exclusive boolean Is this an exclusive connection autodelete boolean Should this queue be deleted on client disconnection durable boolean Create a durable queue clientid string Use the following client id subscription boolean Create a subscription to this destination routingkey string Use this value as the routing key While the code has the following options, public static final String OPTION_EXCLUSIVE = exclusive; public static final String OPTION_AUTODELETE = autodelete; public static final String OPTION_DURABLE = durable; public static final String OPTION_BROWSE = browse; public static final String OPTION_CLIENTID = clientid; public static final String OPTION_SUBSCRIPTION = subscription; public static final String OPTION_ROUTING_KEY = routingkey; public static final String OPTION_BINDING_KEY = bindingkey; public static final String OPTION_REJECT_BEHAVIOUR = rejectbehaviour; (*) Multiple Binding keys can be specified. While most of the options are quite straight forward I'm trying to figure out the intended behaviour for a few. 1. Subscription What's the intended usage for subscription ? All though the wiki lists it as a boolean it has been used in a rather bizarre way in the BindingURLParser.java (All though I was the author of BindingURLParser I simply used the same that was there in the old code). Could we remove this option? 2. Client ID We don't use the queue-name worked out here in anyway when we create the durable subscription name. Could we remove this option ? 3. OPTION_REJECT_BEHAVIOUR Could somebody please explain the intended behaviour for this option so I could correctly pass it when creating the address structure out of a BURL. Regards, Rajith - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
QPID-3849 - Client connection breaks broker-to-broker cluster SASL authentication
Hi guys, I reported https://issues.apache.org/jira/browse/QPID-3849 three months ago... just wondering if anyone is able to offer any comments on it? Does it sound like something I'm doing wrong, or a legitimate Qpid issue? I'd love to know if this is consistently reproducible by others (as it is for me), or if its something unique to my environment. Thanks :) pc http://colby.id.au
[jira] [Updated] (QPID-3849) Client connection breaks broker-to-broker cluster SASL authentication
[
https://issues.apache.org/jira/browse/QPID-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Colby updated QPID-3849:
-
Affects Version/s: 0.16
Client connection breaks broker-to-broker cluster SASL authentication
-
Key: QPID-3849
URL: https://issues.apache.org/jira/browse/QPID-3849
Project: Qpid
Issue Type: Bug
Components: C++ Clustering
Affects Versions: 0.14, 0.16
Environment: CentOS release 5.5 (Final)
Linux version 2.6.18-194.32.1.el5 (mockbu...@builder10.centos.org) (gcc
version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Wed Jan 5 17:52:25 EST 2011
Reporter: Paul Colby
Assignee: michael j. goulish
Priority: Critical
Labels: SASL
There is a very strange problem that causes ordinary C++ clients to break C++
broker cluster authentication.
I have two brokers, let's call them {{gateway03}} and {{gateway04}}. They
are both configured to cluster using SSL and CRAM-MD5 (see their
configuration files / environment below).
h3. Scenario 1
This scenario works fine. I'm simply reporting it to show that it does work.
# I start the broker on {{gateway04}}.
# I start the broker on {{gateway03}}.
# {{gateway03}} discovers the cluster.
# {{gateway03}} creates a new persistent store.
# {{gateway03}} receives updates from {{gateway04}}
# {{gateway03}} caught-up
# {{gateway04}} marks store as dirty (no longer last man standing).
# Start as many of my C++ clients as I want, and they all connect with no
issues (note, I've included a sample C++ client that I used to test below,
but the same happens with a number of fully-fledged C++ client applications
I've written too).
This is all perfect! :)
h3. Scenario 2
This is the one that reveals a problem :(
# I start the broker on {{gateway04}}.
#* I *don't* start the broker on {{gateway03}} yet.
# I start one or more C++ clients on {{gateway04}} (or {{gateway03}} telling
the client to connect to {{gateway04}}) (see sample C++ client code below).
# C++ clients all connect correctly, with no issues.
# I start the broker on {{gateway03}}.
# {{gateway03}} discovers the cluster.
# {{gateway03}} creates a new persistent store.
#* Up to this point the results of the two scenarios is the same, just the
order is different.
# The broker on {{gateway03}} reports warning Client closed connection with
501: Desired mechanism(s) not valid: CRAM-MD5 (supported: ANONYMOUS PLAIN)
then critical cluster(192.168.9.90:24784 UPDATEE) catch-up connection closed
prematurely.
# At the same time {{gateway04}} reports warning Closing connection due to
Desired mechanism(s) not valid: CRAM-MD5 (supported: ANONYMOUS PLAIN)} then
error sending update: Desired mechanism(s) not valid: CRAM-MD5 (supported:
ANONYMOUS PLAIN)
# Then, of course, the broker on {{gateway03}} shuts down.
Note, more complete broker / client logs are included below.
So, it seems that somehow once an ordinary C++ client (ie not another broker)
connects to the broker, the broker no longer accepts CRAM-MD5 authentication
from other joining brokers. But already-joined brokers participating in the
cluster are not affected.
This may be the result of some misconfiguration on my part, but looks like a
pretty serious clustering bug to me... ?
Some further notes:
* I don't know at this stage if the use of SSL has any affect (ie I haven't
tried these same tests with SSL turned off).
* it doesn't matter which broker is started first - I can swap {{gateway03}}
and {{gateway04}} in every instance, and the result is the same.
* I have a third broker that I use as part of this cluster, and it sees that
same affect. If, for example, I have two brokers clustered, and a client
connects, then the third broker will not be able to join the cluster for the
same reason as above.
h3. Broker Configuration
The {{gateway03}} broker is configured as follows ({{gateway04}} config is
the same, but with {{03}} replaced with {{04}} where relevant).
{code:title=/etc/qpidd.conf}
cluster-name=mm-queue-cluster
cluster-mechanism=CRAM-MD5
cluster-username=guest
cluster-password=guest
cluster-size=0
cluster-url=ssl:gateway03:5671
auth=yes
ssl-cert-db=/etc/qpid/certs/broker
ssl-cert-password-file=/etc/qpid/certs/pass.txt
ssl-cert-name=broker
require-encryption=yes
{code}
{code:title=/etc/sasl2/qpidd.conf}
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /var/lib/qpidd/qpidd.sasldb
mech_list: CRAM-MD5 DIGEST-MD5 PLAIN
sql_select: dummy select
{code}
{code:title=broker environment}
export QPID_SSL_CERT_DB=/etc/qpid/certs/broker
export QPID_SSL_CERT_NAME=broker
export QPID_SSL_CERT_PASSWORD_FILE=/etc/qpid/certs/pass.txt
{code}
h3. Sample Test Client
{code:title=main.cpp}
#include
[jira] [Commented] (QPID-4001) Add a java version of the Qpid API
[ https://issues.apache.org/jira/browse/QPID-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276434#comment-13276434 ] Rajith Attapattu commented on QPID-4001: As the first step we should agree on how the Qpid API in java should like. while a lot of it is going to be determined by the already available versions for python and C++, there will still be a few slight differences to conform to the java idioms. Add a java version of the Qpid API -- Key: QPID-4001 URL: https://issues.apache.org/jira/browse/QPID-4001 Project: Qpid Issue Type: New Feature Components: Java Client Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.17 Both C++ and Python have a common API that is commonly referred to as the Qpid API. There have been numerous requests to add one for Java. The consensus we have so far for the upcomming new client is to have the following layering where the Qpid API is a major component. proton-j -- Qpid API -- JMS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3996) [Java Broker] Update optional BDB dependency to use latest version
[ https://issues.apache.org/jira/browse/QPID-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3996: --- Comment: was deleted (was: As the first step we should agree on how the Qpid API in java should like. while a lot of it is going to be determined by the already available versions for python and C++, there will still be a few slight differences to conform to the java idioms.) [Java Broker] Update optional BDB dependency to use latest version -- Key: QPID-3996 URL: https://issues.apache.org/jira/browse/QPID-3996 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Broker BDB Store Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 Update dependency to latest version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
