Re: Little patch to make both python tests work (was: one of)
Hi Rajith!
On Fri, Mar 12, 2010 at 09:41:47AM -0500, Rajith Attapattu wrote:
Could you please create a JIRA and attach the patch there.
(Pls make sure to tick the check box granting the license.)
But this is a patch for store. Should I create a JIRA for fix in
RHM store module?
Probably I am writing to wrong list, but rhemrg-users-l...@redhat.com
seems to be pretty unresponsive.
By the way, I fixed the other error as well, complete patch attached.
Thanks, Ján
diff --git a/cpp/tests/run_old_python_tests b/cpp/tests/run_old_python_tests
index 0b1197d..1add120 100755
--- a/cpp/tests/run_old_python_tests
+++ b/cpp/tests/run_old_python_tests
@@ -40,7 +40,8 @@ EOF
fi
QPID_PYTHON_DIR=${QPID_DIR}/python
-export PYTHONPATH=${QPID_PYTHON_DIR}:${abs_srcdir}
+QPID_QMF_DIR=${QPID_DIR}/extras/qmf/build/lib
+export PYTHONPATH=${QPID_PYTHON_DIR}:${QPID_QMF_DIR}:${abs_srcdir}
if python -c import qpid ; then
PYTHON_TESTS=
diff --git a/cpp/tests/system_test.sh b/cpp/tests/system_test.sh
index 8de66f9..8ac42c9 100755
--- a/cpp/tests/system_test.sh
+++ b/cpp/tests/system_test.sh
@@ -32,7 +32,7 @@ fi
xml_spec=$QPID_DIR/specs/amqp.0-10-qpid-errata.xml
test -f $xml_spec || error $xml_spec not found: invalid \$QPID_DIR ?
-export PYTHONPATH=$QPID_DIR/python
+export PYTHONPATH=$QPID_DIR/python:$QPID_DIR/extras/qmf/build/lib
echo Using directory $TMP_DATA_DIR
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Client configuration Connection URL
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conwayacon...@redhat.com wrote:
On 03/11/2010 06:41 PM, Rajith Attapattu wrote:
Hi All,
Currently quite a bit of options can be configured via the Java
Connection URL, which tends to make it ungainly and quite error prone.
If we are to think in terms of a Connection String instead of a
Connection URL , then I believe we could come up with a more simpler
solution.
Therefore I'd like to make the following proposals.
1) Introduce a simple scheme for a Connection String ( inspired by
the new addressing format)
2) Also allow the ability to specify the config using a property file.
* I hate having to specify user/pass when the auth mech (ex kerberos)
is not even using it. Therefore it should be optional !
1. 0 Connection String
---
1.1 Examples
tcp://localhost
tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
ssl-trust-store : ~/cert.jks ..}
tcp://host1.example.com; {user: bob, pass: nuts} ,
tcp://host2.example.com; {user: ding, pass: dong} ...
I think there is value in keeping to a URL-friendly
Could you please elaborate on this?
I mean avoiding characters that are not allowed in URLs, in particular spaces
which are troublesome in a variety of contexts. However I if the spaces are
optional (I think they are given that there are always other separators involved
,:{} then that may not be an issue.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2448) qpid::client::ConnectionImpl::addSession does not raise an exception if no channel number is available.
qpid::client::ConnectionImpl::addSession does not raise an exception if no channel number is available. --- Key: QPID-2448 URL: https://issues.apache.org/jira/browse/QPID-2448 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.6 Reporter: Alan Conway Assignee: Alan Conway qpid::client::ConnectionImpl::addSession does not raise an exception if no channel number is available, it silently fails to allocate a channel. It should throw a ResourceLimitExceededException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Client configuration Connection URL
On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
Hi All,
Currently quite a bit of options can be configured via the Java
Connection URL, which tends to make it ungainly and quite error prone.
If we are to think in terms of a Connection String instead of a
Connection URL , then I believe we could come up with a more simpler
solution.
Therefore I'd like to make the following proposals.
1) Introduce a simple scheme for a Connection String ( inspired by
the new addressing format)
2) Also allow the ability to specify the config using a property file.
* I hate having to specify user/pass when the auth mech (ex kerberos)
is not even using it. Therefore it should be optional !
1. 0 Connection String
---
1.1 Examples
tcp://localhost
tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
ssl-trust-store : ~/cert.jks ..}
tcp://host1.example.com; {user: bob, pass: nuts} ,
tcp://host2.example.com; {user: ding, pass: dong} ...
1.2 Syntax
broker [ ;options ] [ ,broker [ ;options ]] *
Where broker is::
protocol:// [ host [ : port ] ](protocol = {tcp|vm|rdma}
The c++ client currently supports the AMQP 0-10 definition of a url
syntax. Do we want to support that more widely? It would be good to
improve consistency across clients a little.
The approach for specifying SSL is also different across the different
clients.
Where options is::
{key :value, ... }
And values may be:
- numbers
- single, double, or non quoted strings
- maps (dictionaries)
- lists
2.0 Config file
-
Example
JNDI prop file
connection.my-connection = tcp://localhost; {id : 1}
connection.my-con = tcp://host1.example.com; {id: 2} ,
tcp://host2.example.com; {id: 2}, tcp://host3.example.com; {id: 3}
I'm not hugely keen on the split file approach or on the id as a way to
reference externally defined options. What is the motivation for that?
=Connection.properties=
con id : 1 {
ssl: true
sasl-mech : EXTERNAL
ssl-trust-store : ~/cert.jks
ssl-key-store : ~/keys.jks
ssl-verify-hostname : true
}
con id : 1 {
sasl-mech : GSSAPI
sasl-hostname : host1.example.com
sasl-protocol : qpidd
sasl-encryption : true
tcp-nodelay : true
}
con id : 3 {
user : ding
pass : dong
tcp-nodelay : true
}
==
Connection.properties can be loaded from the classpath or specified as
an option in the connection string.
(You could also trivially have a connection property file per connection).
Comments and suggestions are most welcomed !
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
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: Client configuration Connection URL
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim g...@redhat.com wrote:
On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
Hi All,
Currently quite a bit of options can be configured via the Java
Connection URL, which tends to make it ungainly and quite error prone.
If we are to think in terms of a Connection String instead of a
Connection URL , then I believe we could come up with a more simpler
solution.
Therefore I'd like to make the following proposals.
1) Introduce a simple scheme for a Connection String ( inspired by
the new addressing format)
2) Also allow the ability to specify the config using a property file.
* I hate having to specify user/pass when the auth mech (ex kerberos)
is not even using it. Therefore it should be optional !
1. 0 Connection String
---
1.1 Examples
tcp://localhost
tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
ssl-trust-store : ~/cert.jks ..}
tcp://host1.example.com; {user: bob, pass: nuts} ,
tcp://host2.example.com; {user: ding, pass: dong} ...
1.2 Syntax
broker [ ;options ] [ ,broker [ ;options ]] *
Where broker is::
protocol:// [ host [ : port ] ] (protocol = {tcp|vm|rdma}
The c++ client currently supports the AMQP 0-10 definition of a url syntax.
Do we want to support that more widely? It would be good to improve
consistency across clients a little.
Well my motivation behind the thread was to get this out in the open.
IMO I think we as a project *must* have the same connection url/string
syntax across all clients.
I thought I'd start with the Java side and then take it from there.
The connection URL has been used for two reasons.
1) To identify which broker(s) to connect to
2) As a configuration mechanism.
My issue is if we treat the whole thing as a URL then supporting the
latter makes the whole thing ugly and error prone.
The Java connection url is a case in point.
I would rather treat it as a connection string which consists of two
**distinct** parts.
a) A broker (identified by a URL - ex tcp://localhost:5672/vhost )
b) A bunch of key:value pairs associated with the broker url.
Based on past experience, munging them together to form a URL is a
good recipe for disaster.
The approach for specifying SSL is also different across the different
clients.
Which is a pity I think.
Where options is::
{key :value, ... }
And values may be:
- numbers
- single, double, or non quoted strings
- maps (dictionaries)
- lists
2.0 Config file
-
Example
JNDI prop file
connection.my-connection = tcp://localhost; {id : 1}
connection.my-con = tcp://host1.example.com; {id: 2} ,
tcp://host2.example.com; {id: 2}, tcp://host3.example.com; {id: 3}
I'm not hugely keen on the split file approach or on the id as a way to
reference externally defined options. What is the motivation for that?
Sometimes the connection string gets quite crowded especially if you
have a few props to specify.
I was just exploring the possibility of pushing that part to a config file.
Another advantage of the given format is that it makes it easy to see
the diffs btw different versions of the config file, something that is
quite impossible with the current approach.
Through experience I have seen that most companies version control the
deployment descriptors/config files etc., so that any given time they
could rollback to a previous deployment.
Rather than talk things in the abstract I decided to express my
questions/ideas via a proposal.
Therefore I was more keen on getting it out quickly with some
examples, than coming up with a solid proposal.
I hope the latter objective could be achieved through a discussion
that starts of from some basic idea.
=Connection.properties=
con id : 1 {
ssl: true
sasl-mech : EXTERNAL
ssl-trust-store : ~/cert.jks
ssl-key-store : ~/keys.jks
ssl-verify-hostname : true
}
con id : 1 {
sasl-mech : GSSAPI
sasl-hostname : host1.example.com
sasl-protocol : qpidd
sasl-encryption : true
tcp-nodelay : true
}
con id : 3 {
user : ding
pass : dong
tcp-nodelay : true
}
==
Connection.properties can be loaded from the classpath or specified as
an option in the connection string.
(You could also trivially have a connection property file per connection).
Comments and suggestions are most welcomed !
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
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: Client configuration Connection URL
On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway acon...@redhat.com wrote:
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conwayacon...@redhat.com wrote:
On 03/11/2010 06:41 PM, Rajith Attapattu wrote:
Hi All,
Currently quite a bit of options can be configured via the Java
Connection URL, which tends to make it ungainly and quite error prone.
If we are to think in terms of a Connection String instead of a
Connection URL , then I believe we could come up with a more simpler
solution.
Therefore I'd like to make the following proposals.
1) Introduce a simple scheme for a Connection String ( inspired by
the new addressing format)
2) Also allow the ability to specify the config using a property file.
* I hate having to specify user/pass when the auth mech (ex kerberos)
is not even using it. Therefore it should be optional !
1. 0 Connection String
---
1.1 Examples
tcp://localhost
tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
ssl-trust-store : ~/cert.jks ..}
tcp://host1.example.com; {user: bob, pass: nuts} ,
tcp://host2.example.com; {user: ding, pass: dong} ...
I think there is value in keeping to a URL-friendly
Could you please elaborate on this?
I mean avoiding characters that are not allowed in URLs, in particular
spaces which are troublesome in a variety of contexts. However I if the
spaces are optional (I think they are given that there are always other
separators involved ,:{} then that may not be an issue.
Alan I think we should treat the Broker portion of it as a URL and
the key : value pairs separately.
IMO opinion they are two distinct entities that should be treated separately.
The Connection **String** is just a convenient way of expressing them together.
The broker part is to figure out where the broker is and the latter is
to configure the client options, but scoped by the given connection.
I really don't see any advantage in treating the whole string as a URL.
Perhaps I missed something?
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-2448) qpid::client::ConnectionImpl::addSession does not raise an exception if no channel number is available.
[ https://issues.apache.org/jira/browse/QPID-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed QPID-2448. - Resolution: Fixed Fixed in r923415 qpid::client::ConnectionImpl::addSession does not raise an exception if no channel number is available. --- Key: QPID-2448 URL: https://issues.apache.org/jira/browse/QPID-2448 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.6 Reporter: Alan Conway Assignee: Alan Conway qpid::client::ConnectionImpl::addSession does not raise an exception if no channel number is available, it silently fails to allocate a channel. It should throw a ResourceLimitExceededException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Client configuration Connection URL
On 03/15/2010 05:48 PM, Rajith Attapattu wrote:
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Simg...@redhat.com wrote:
On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
1.2 Syntax
broker[ ;options] [ ,broker[ ;options]] *
Where broker is::
protocol:// [ host [ : port ] ](protocol = {tcp|vm|rdma}
The c++ client currently supports the AMQP 0-10 definition of a url syntax.
Do we want to support that more widely? It would be good to improve
consistency across clients a little.
Well my motivation behind the thread was to get this out in the open.
IMO I think we as a project *must* have the same connection url/string
syntax across all clients.
I thought I'd start with the Java side and then take it from there.
Understood. I am responding by pointing out that there is a url scheme
defined in the 0-10 specification which is currently used by the c++
client. The question of whether we want to support that more widely
seems to me to be worth answering early in any proposal around
unification of url schemes (whichever way we answer it).
The connection URL has been used for two reasons.
1) To identify which broker(s) to connect to
2) As a configuration mechanism.
Isn't the former a specific case for the latter?
My issue is if we treat the whole thing as a URL then supporting the
latter makes the whole thing ugly and error prone.
The Java connection url is a case in point.
I would rather treat it as a connection string which consists of two
**distinct** parts.
a) A broker (identified by a URL - ex tcp://localhost:5672/vhost )
b) A bunch of key:value pairs associated with the broker url.
You could of course view the url as one of the set of options that can
be configured via the key-value pairs...
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Client configuration Connection URL
On Mon, Mar 15, 2010 at 4:25 PM, Gordon Sim g...@redhat.com wrote:
On 03/15/2010 05:48 PM, Rajith Attapattu wrote:
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Simg...@redhat.com wrote:
On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
1.2 Syntax
broker [ ;options ] [ ,broker [ ;options ]] *
Where broker is::
protocol:// [ host [ : port ] ] (protocol = {tcp|vm|rdma}
The c++ client currently supports the AMQP 0-10 definition of a url
syntax.
Do we want to support that more widely? It would be good to improve
consistency across clients a little.
Well my motivation behind the thread was to get this out in the open.
IMO I think we as a project *must* have the same connection url/string
syntax across all clients.
I thought I'd start with the Java side and then take it from there.
Understood. I am responding by pointing out that there is a url scheme
defined in the 0-10 specification which is currently used by the c++ client.
The question of whether we want to support that more widely seems to me to
be worth answering early in any proposal around unification of url schemes
(whichever way we answer it).
Actually the Java client did support the 0-10 URL format at one point.
But then it got dropped for reasons I can't clearly remember.
Perhaps the archives and svn log might yield some clues.
The connection URL has been used for two reasons.
1) To identify which broker(s) to connect to
2) As a configuration mechanism.
Isn't the former a specific case for the latter?
It is and as you have mentioned below, the URL is infact one of the
options in the connection String.
However in my proposal I gave it a prominent place by moving it out of
the curly brackets.
My issue is if we treat the whole thing as a URL then supporting the
latter makes the whole thing ugly and error prone.
The Java connection url is a case in point.
I would rather treat it as a connection string which consists of two
**distinct** parts.
a) A broker (identified by a URL - ex tcp://localhost:5672/vhost )
b) A bunch of key:value pairs associated with the broker url.
You could of course view the url as one of the set of options that can be
configured via the key-value pairs...
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Qpid Wiki in DocBook
On Thu, Mar 11, 2010 at 2:31 PM, Jonathan Robie jonathan.ro...@redhat.com wrote: Here's a PDF built from the Qpid Wiki, converted to DocBook: http://people.apache.org/~jonathan/qpid-book.pdf This is all kinds of awesome. I'd also like to get some other people working on this with me. I'd particularly like to get someone to be in charge of the section on the Java Broker. I'll try to update this when I get back to the land of real internet next week, my 3G mobile broadband thing does not play well with svn or large downloads atm. In general I'd argue that changes which require doc changes should include them as part of the patch. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2337) SubscriptionManager::start() does not handle exceptions from dispatch
[
https://issues.apache.org/jira/browse/QPID-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845672#action_12845672
]
Tom McCubbin commented on QPID-2337:
After spending a few hours on this (yeah...should have been a bit quicker...) I
came to the same conclusion. I was happy to find the
SubscriptionManager::start() method that starts a new thread from whence msgs
can be dispatched. Until I found out that start() which is handled via the
qpid::client::Dispatcher just fires a thread which calls
qpid::client::Dispatcher::run(). Run in turn may throw a ClosedException,
TransportFailure, or std::exception.
When in a separate thread, any exceptions are unhandled and result in the
untimely demise of that thread and every other thread, unless I make wild
presumptions in my unhandled exception handler, which is not realistic.
Furthermore, ClosedException and TransportFailure do not call the
failoverHandler, yet std::exceptions do? This seems quite awkward. If you start
w/out a broker available, it reliably calls the failoverHandler(). If however
you crash the server, it throws and you are done.
As any old code-monkey does, I assume at some point the connected server will
crash. Not if, but when. This behaviour is not acceptable.
To fix it, I did two very simple things. Both change
qpidc-0.5/src/qpid/client/Dispatcher.cpp (no header change)
1) I changed the qpid::client::Dispatcher::run() method so if there is an
exception, ANY TYPE, and if there is a failoverHandler registered that handler
will be called, and no exception will be thrown
Added below: (+++ and the 'e' for the first 2 catch clauses )
catch (const ClosedException e) {
+++ if ( failoverHandler ) {
+++ QPID_LOG(debug, QPID_MSG(session.getId() failover: e.what()));
+++ failoverHandler();
+++ } else {
QPID_LOG(debug, QPID_MSG(session.getId() : closed by peer));
+++ }
}
catch (const TransportFailure e) {
+++ if ( failoverHandler ) {
+++ QPID_LOG(debug, QPID_MSG(session.getId() failover: e.what()));
+++ failoverHandler();
+++ } else {
QPID_LOG(info, QPID_MSG(session.getId() : transport failure));
throw;
+++ }
}
catch (const std::exception e) {
if ( failoverHandler ) {
QPID_LOG(debug, QPID_MSG(session.getId() failover:
e.what()));
failoverHandler();
} else {
QPID_LOG(error, session.getId() error: e.what());
throw;
}
}
2) when the qpid::client::Dispatcher::start() method is called, if there is no
failoverHandler registered, I register an anonymous dummy function I added to
the same .cpp file. Looks like this.
+++namespace {
+++ void dumbHandler() { }
+++}
void Dispatcher::start()
{
+++ if ( ! failoverHandler )
+++ registerFailoverHandler( dumbHandler );
worker = Thread(this);
}
This is working wonderfully for me so far. Yeah, its not perfect, but hey its
quicker than adding my own thread which can have the try/catch code to wrap the
run() method.
In practice, if you register a failureCallback on the qpid::client::Connection
to handle these errors you need not worry about any other handler for
SubscriptionManager(s) and the code above will bring you quickly to Shangri La.
If you want, you can still register a failureCallback on the
SubscriptionManager and provided you use my modified run() method, you will be
ok as well.
If anyone wants a patch, let me know.
SubscriptionManager::start() does not handle exceptions from dispatch
-
Key: QPID-2337
URL: https://issues.apache.org/jira/browse/QPID-2337
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.5, 0.6
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.7
...so any exceptions thrown (e.g. when connection is lost) will cause client
process to terminate if start() is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
