[jira] Updated: (QPID-2953) Qpid Cpp Messaging .NET Binding does not include unit tests
[ https://issues.apache.org/jira/browse/QPID-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2953: - Affects Version/s: (was: 0.9) 0.8 Fix Version/s: (was: 0.8) 0.9 > Qpid Cpp Messaging .NET Binding does not include unit tests > --- > > Key: QPID-2953 > URL: https://issues.apache.org/jira/browse/QPID-2953 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.8 > Environment: Windows build >Reporter: Chuck Rolke >Assignee: Chuck Rolke > Fix For: 0.9 > > > The .NET Binding solution includes a project named Test\messaging.test. This > directory is disorganized with respect to a formal test suite. -- 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
[jira] Updated: (QPID-2930) JMS msg.getPropertyNames() method should not return x-amqp-0-10.routing-key
[
https://issues.apache.org/jira/browse/QPID-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPID-2930:
-
Fix Version/s: (was: 0.8)
0.9
> JMS msg.getPropertyNames() method should not return x-amqp-0-10.routing-key
>
>
> Key: QPID-2930
> URL: https://issues.apache.org/jira/browse/QPID-2930
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
>Priority: Minor
> Fix For: 0.9
>
>
> Description of problem:
> JMS msg.getPropertyNames() method should not return x-amqp-0-10.routing-key,
> x-amqp-0-10.routing-key is internal property. It cause exception if loop via
> ProertyName enumeration.
> Code:
> ===
> Enumeration enu = msg.getPropertyNames();
> while (enu.hasMoreElements()) {
> String name = (String) enu.nextElement();
> String value = msg.getStringProperty(name);
> }
> Exception
> =
> Caused by: javax.jms.MessageFormatException:
> getString("x-amqp-0-10.routing-key") failed as value of type class [B is an
> array.
> at
> org.apache.qpid.client.message.AMQMessageDelegate_0_10.getStringProperty(AMQMessageDelegate_0_10.java:639)
>
> at
> org.apache.qpid.client.message.AbstractJMSMessage.getStringProperty(AbstractJMSMessage.java:254)
>
--
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
[jira] Updated: (QPID-2914) address parser doesn't recognize None
[ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2914: - Fix Version/s: (was: 0.8) 0.9 > address parser doesn't recognize None > - > > Key: QPID-2914 > URL: https://issues.apache.org/jira/browse/QPID-2914 > Project: Qpid > Issue Type: Bug > Components: Python Client >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.9 > > > The address parser treats None as an ID rather than as a special token. -- 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: [jira] Updated: (QPID-2914) address parser doesn't recognize None
Is it too late to get this onto the RC branch for 0.8? The fix is on trunk and fairly isolated. It just needs to be merged over. --Rafael On 11/22/2010 07:39 AM, Robbie Gemmell (JIRA) wrote: [ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2914: - Fix Version/s: (was: 0.8) 0.9 address parser doesn't recognize None - Key: QPID-2914 URL: https://issues.apache.org/jira/browse/QPID-2914 Project: Qpid Issue Type: Bug Components: Python Client Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.9 The address parser treats None as an ID rather than as a special token. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934455#action_12934455 ] Ted Ross commented on QPID-2949: >>TODO -- also must fix the pathway where auth==yes. This is important since the problem isn't the state of the --auth configuration but the fact that a server process is prompting for interactive input. >>NOTE: this is apparently an irritant rather than a disaster, since it did not >>affect make check >>after the original checkin ( r102451 ). I disagree with this statement. All this means is that make-check has insufficient coverage. If a server process is hanging while waiting for interactive input, I'd say that's closer to disaster than irritant. > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_noauth.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Commented: (QPID-2930) JMS msg.getPropertyNames() method should not return x-amqp-0-10.routing-key
[
https://issues.apache.org/jira/browse/QPID-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934472#action_12934472
]
Andrew Kennedy commented on QPID-2930:
--
But, why are you trying to get this property value as a String in the first
place?
This is a byte array, so I think the exception is correct in this circumstance.
If I set *any* byte array property then the code you describe will fail in the
same way. Additionally, I don't think we want to go down the road of
special-casing property names to be 'hidden' from the returned enumeration of
property names. I would think thst if a property is set, on the message, and
*can* be retreived its name should be returned.
Finally, would it be possible, instead, to fix this by setting the value as a
String in the first place? I assume this is the C++ broker, where
OutgoingMessage.cpp and IncomingMessage.cpp seem to define this as const
std::string X_ROUTING_KEY("x-amqp-0-10.routing-key");
> JMS msg.getPropertyNames() method should not return x-amqp-0-10.routing-key
>
>
> Key: QPID-2930
> URL: https://issues.apache.org/jira/browse/QPID-2930
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
>Priority: Minor
> Fix For: 0.9
>
>
> Description of problem:
> JMS msg.getPropertyNames() method should not return x-amqp-0-10.routing-key,
> x-amqp-0-10.routing-key is internal property. It cause exception if loop via
> ProertyName enumeration.
> Code:
> ===
> Enumeration enu = msg.getPropertyNames();
> while (enu.hasMoreElements()) {
> String name = (String) enu.nextElement();
> String value = msg.getStringProperty(name);
> }
> Exception
> =
> Caused by: javax.jms.MessageFormatException:
> getString("x-amqp-0-10.routing-key") failed as value of type class [B is an
> array.
> at
> org.apache.qpid.client.message.AMQMessageDelegate_0_10.getStringProperty(AMQMessageDelegate_0_10.java:639)
>
> at
> org.apache.qpid.client.message.AbstractJMSMessage.getStringProperty(AbstractJMSMessage.java:254)
>
--
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: JMS Client reconnect
Is the failover for a cluster or just to brokers. For a cluster, the heartbeat etc need to be setup and the rest is automatic from the failover exchange. If just two brokers, then the connection URL needs to be used. Carl. On 11/21/2010 03:30 PM, Tim Chen wrote: Anyone? Tim On Thu, Nov 18, 2010 at 2:10 PM, Tim Chen wrote: Hi all, I wonder what's the best way to handle reconnect to the broker when broker is unavailable (network is down / broker crashed, etc) using Java JMS client to C++ broker? Currently when using the JMS client when the broker is killed, a runtime exception ( ConnectionException ) is thrown internally in qpid and I don't see a way I can get this exception. I tried to add a check each time it sends a message if the broker connection is closed ( AMQConnection.isClosed() ) to re-attempt to reconnect. However, I see that if the broker is disconnected not via AMQConnection.close(), the state is never set to CLOSED and still set as OPEN. From reading this: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/pdf/Programming_in_Apache_Qpid/Red_Hat_Enterprise_MRG-1.3-Programming_in_Apache_Qpid-en-US.pdf It has reconnect flags on using Python and C++ clients to automatically reconnect if connection is lost. But I wonder what's the best way to do this in JMS client? Thanks, Tim - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: qpid-config and 0.8 client distributions
Running these requires the QMF bits (qpid/extras/qmf) and the Python client. What's the best way to handle these dependencies? Jonathan On 11/21/2010 02:15 PM, Robbie Gemmell wrote: It's not too late to add it, but that doesn't necessarily mean it's going to make it in either. I'm assuming ./setup.py sdist was to be run in the qpid/tools directory? The artifact produced by doing that has no LICENCE, NOTICE, or (as ./setup.py complains about) README files. The first two are required and the last would appear necessary to tell you what to do with these files once you have them, as e.g. the archive doesn't include the Python client (which is fair enough, but needs documented for those that don't know its required), and aren't there also other files required for general QMF functionality, or are those included with the python client? The file listing seems a little light: qpid-tools-0.8/ qpid-tools-0.8/src/ qpid-tools-0.8/src/py/ qpid-tools-0.8/src/py/qpid-route qpid-tools-0.8/src/py/qpid-tool qpid-tools-0.8/src/py/qpid-cluster qpid-tools-0.8/src/py/qpid-config qpid-tools-0.8/src/py/qpid-cluster-store qpid-tools-0.8/src/py/qpid-stat qpid-tools-0.8/src/py/qpid-queue-stats qpid-tools-0.8/src/py/qpid-printevents qpid-tools-0.8/setup.py qpid-tools-0.8/PKG-INFO If someone who knows what bits are needed / where they are / how to use them etc wants to make some updates on trunk to produce a useful artifact for the management tools then I would be happy to include that in the next RC. I intend to produce RC3 tomorrow night (Monday 22nd), from about 9pm GMT. If someone wants to take a shot at this could you either do so before then or let us all know that you are going to imminently and I will hold off until it's ready, otherwise I would suggest it will just have to wait for the next release. Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: qpid-config and 0.8 client distributions
I think anything required that isnt already easily available in another archive needs to be included in the new tools archive. E.g. downloading the full-release archive to extract 'qpid/extras/qmf' would obviously be a bit much given it has 50+MB of other stuff in it, but making people download the standalone python client archive which is required in full wouldnt be too bad. Robbie On 22 November 2010 14:36, Jonathan Robie wrote: > Running these requires the QMF bits (qpid/extras/qmf) and the Python client. > What's the best way to handle these dependencies? > > Jonathan > > On 11/21/2010 02:15 PM, Robbie Gemmell wrote: >> >> It's not too late to add it, but that doesn't necessarily mean it's going >> to make it in either. >> >> I'm assuming ./setup.py sdist was to be run in the qpid/tools directory? >> The artifact produced by doing that has no LICENCE, NOTICE, or (as >> ./setup.py complains about) README files. The first two are required and the >> last would appear necessary to tell you what to do with these files once you >> have them, as e.g. the archive doesn't include the Python client (which is >> fair enough, but needs documented for those that don't know its required), >> and aren't there also other files required for general QMF functionality, or >> are those included with the python client? The file listing seems a little >> light: >> >> qpid-tools-0.8/ >> qpid-tools-0.8/src/ >> qpid-tools-0.8/src/py/ >> qpid-tools-0.8/src/py/qpid-route >> qpid-tools-0.8/src/py/qpid-tool >> qpid-tools-0.8/src/py/qpid-cluster >> qpid-tools-0.8/src/py/qpid-config >> qpid-tools-0.8/src/py/qpid-cluster-store >> qpid-tools-0.8/src/py/qpid-stat >> qpid-tools-0.8/src/py/qpid-queue-stats >> qpid-tools-0.8/src/py/qpid-printevents >> qpid-tools-0.8/setup.py >> qpid-tools-0.8/PKG-INFO >> >> If someone who knows what bits are needed / where they are / how to use >> them etc wants to make some updates on trunk to produce a useful artifact >> for the management tools then I would be happy to include that in the next >> RC. I intend to produce RC3 tomorrow night (Monday 22nd), from about 9pm >> GMT. If someone wants to take a shot at this could you either do so before >> then or let us all know that you are going to imminently and I will hold off >> until it's ready, otherwise I would suggest it will just have to wait for >> the next release. >> >> Robbie > > - > 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: JMS Client reconnect
On Thu, Nov 18, 2010 at 5:10 PM, Tim Chen wrote: > Hi all, > > I wonder what's the best way to handle reconnect to the broker when broker > is unavailable (network is down / broker crashed, etc) using Java JMS > client > to C++ broker? > Are you running a cluster or is it a bunch of standalone brokers ? > Currently when using the JMS client when the broker is killed, a runtime > exception ( ConnectionException ) is thrown internally in qpid and I don't > see a way I can get this exception. > > The Qpid JMS client supports transparent failover if configured properly. If you are running a cluster then --- For c++ broker you can set the failover method to "failover_exchange" and the client will transparently retrieve the available brokers from the cluster and will connect to one of them if the current broker fails. Ex amqp://guest:gu...@clientid /testpath?brokerlist='tcp://localhost:5672'&failover='failover_exchange' If you are running a set of standalone brokers --- You can set the failover method to round robin an provide a list of brokers. Ex amqp://guest:gu...@clientid /testpath?brokerlist='tcp://host1:5672;tcp://host2:5672..;tcp://hostn:5672'&failover='roundrobin' Also if all attempts are unsuccessful (i.e total cluster failure or all brokers in the list are down) then it will throw an exception if there is a connection listener set. It will not notify a connection exception If and only if it can connect to another broker in the cluster (or the list of brokers if provided with failover=roundrobin). i.e it will not notify any intermediate failures. > I tried to add a check each time it sends a message if the broker > connection > is closed ( AMQConnection.isClosed() ) to re-attempt to reconnect. > > However, I see that if the broker is disconnected not via > AMQConnection.close(), the state is never set to CLOSED and still set as > OPEN. > Please stick to the standard JMS interfaces as internal classes like AMQConnection are subject change from release to release. > > From reading this: > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/pdf/Programming_in_Apache_Qpid/Red_Hat_Enterprise_MRG-1.3-Programming_in_Apache_Qpid-en-US.pdf > > It has reconnect flags on using Python and C++ clients to automatically > reconnect if connection is lost. > > But I wonder what's the best way to do this in JMS client? > > Thanks, > > Tim > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: dont_prompt_me_2.diff obsoletes previous patch this patch provides a way to tell SaslFactory that console interaction is NOT ok. i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error. This script demonstrates that all goes well if you supply enough info : rm -rf /tmp/data_1 /tmp/data_2 mkdir /tmp/data_1 /tmp/data_2 # in window 1: ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config # in window 2: ../qpidd -p 1 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config # in window 3 ( from qpid dir ) ./tools/src/py/qpid-route dynamic add zig/z...@localhost zig/z...@localhost:1 qmf.default.direct # and view the created route ./tools/src/py/qpid-route route list localhost:5672 If you say auth=no, that works fine also. HOWEVER PLEASE NOTE -- if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it. > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_2.diff, dont_prompt_me_2.diff, > dont_prompt_me_2.diff, dont_prompt_me_noauth.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: dont_prompt_me_2.diff obsoletes previous patch this patch provides a way to tell SaslFactory that console interaction is NOT ok.i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error. This script demonstrates that all goes well if you supply enough info : rm -rf /tmp/data_1 /tmp/data_2 mkdir /tmp/data_1 /tmp/data_2 # in window 1: ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config # in window 2: ../qpidd -p 1 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config # in window 3 ( from qpid dir ) ./tools/src/py/qpid-route dynamic add zig/z...@localhost zig/z...@localhost:1 qmf.default.direct # and view the created route ./tools/src/py/qpid-route route list localhost:5672 If you say auth=no, that works fine also. HOWEVER PLEASE NOTE -- if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it. > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_2.diff, dont_prompt_me_2.diff, > dont_prompt_me_2.diff, dont_prompt_me_noauth.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: dont_prompt_me_2.diff > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_2.diff, dont_prompt_me_2.diff, > dont_prompt_me_2.diff, dont_prompt_me_noauth.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: (was: dont_prompt_me_2.diff) > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_2.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: (was: dont_prompt_me_2.diff) > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_2.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no
[ https://issues.apache.org/jira/browse/QPID-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-2949: - Attachment: (was: dont_prompt_me_noauth.diff) > broker prompts console interactively for password when --auth=no > > > Key: QPID-2949 > URL: https://issues.apache.org/jira/browse/QPID-2949 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.8 >Reporter: michael j. goulish >Assignee: michael j. goulish >Priority: Minor > Fix For: 0.9 > > Attachments: dont_prompt_me_2.diff > > > As a result of checkin svn r1024541, which promoted some client-side Sasl > code to the common library for use in broker, the broker now prompts for a > password when when it is run with --auth=no ! > The attached patch removes this behavior by propagating knowledge of > "--auth=no" down to SaslFactory. If authorization has been turned off, the > Saslfactory will create a null sasl object, just like it does if the code is > compiled with no Sasl support. > TODO -- also must fix the pathway where auth==yes. > NOTE: this is apparently an irritant rather than a disaster, since it did not > affect make check after the original checkin ( r102451 ). -- 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
[jira] Created: (QPID-2956) cluster broker exits with "error deliveryRecord no update message."
cluster broker exits with "error deliveryRecord no update message." --- Key: QPID-2956 URL: https://issues.apache.org/jira/browse/QPID-2956 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.9 See https://bugzilla.redhat.com/show_bug.cgi?id=655141 -- 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
[jira] Updated: (QPID-2956) cluster broker exits with "error deliveryRecord no update message."
[ https://issues.apache.org/jira/browse/QPID-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated QPID-2956: -- Description: See https://bugzilla.redhat.com/show_bug.cgi?id=655141 Description of problem: A broker joining a cluster has "error deliveryRecord no update message" which leads to shutdown. Version-Release number of selected component (if applicable):1036871 How reproducible: easy Steps to Reproduce: Apply attached patch to cluster_tests.py and do: make check TESTS=run_cluster_tests CLUSTER_TESTS="*dr_no_message" Actual results: broker exits with error Expected results: no error Additional info: was:See https://bugzilla.redhat.com/show_bug.cgi?id=655141 > cluster broker exits with "error deliveryRecord no update message." > --- > > Key: QPID-2956 > URL: https://issues.apache.org/jira/browse/QPID-2956 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.8 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.9 > > > See https://bugzilla.redhat.com/show_bug.cgi?id=655141 > Description of problem: > A broker joining a cluster has "error deliveryRecord no update message" which > leads to shutdown. > Version-Release number of selected component (if applicable):1036871 > How reproducible: easy > Steps to Reproduce: > Apply attached patch to cluster_tests.py and do: > make check TESTS=run_cluster_tests CLUSTER_TESTS="*dr_no_message" > Actual results: broker exits with error > Expected results: no error > Additional info: -- 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
How easy is it to get Qpid going ?
Hi All, Based on the questions asked on our user list and feedback from customers etc.. it seems that we have plenty of room to improve when it comes to ease of use and documentation. Ease of use is one that directly impacts the first impression about any new product. I firmly believe this is something that needs to be one of the top priorities (if not the top most) for our next release. Perhaps it's time for us to take a step back and see if, 1) Have we packaged our products in a way that is useful for our target users ? 2) How easy is it for folks to download an install our products ? 3) How easy is it for people to run the examples and get it going? 4) Have we organized our documentation properly? 5) Have we got enough documentation to cover atleast the basic aspects? 6) Have we got enough documentation to cover the topics that people are interested once they get the basics going? 7) Are we releasing frequently enough for users to rely on us to ensure that critical bugs are fixed ? 8) Do we as a project have a process that defines how we handle a critical issue after a release ? I am positive that our community (both developers and end users) has a lot of good ideas. I am quite keen on hearing suggestions/comments about the above topics. I will start by replying to my email with what I think about the above questions :) Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
[jira] Resolved: (QPID-2956) cluster broker exits with "error deliveryRecord no update message."
[ https://issues.apache.org/jira/browse/QPID-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-2956. --- Resolution: Fixed Fixed in r1037763 > cluster broker exits with "error deliveryRecord no update message." > --- > > Key: QPID-2956 > URL: https://issues.apache.org/jira/browse/QPID-2956 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.8 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.9 > > > See https://bugzilla.redhat.com/show_bug.cgi?id=655141 > Description of problem: > A broker joining a cluster has "error deliveryRecord no update message" which > leads to shutdown. > Version-Release number of selected component (if applicable):1036871 > How reproducible: easy > Steps to Reproduce: > Apply attached patch to cluster_tests.py and do: > make check TESTS=run_cluster_tests CLUSTER_TESTS="*dr_no_message" > Actual results: broker exits with error > Expected results: no error > Additional info: -- 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: svn commit: r1037771 - /qpid/trunk/qpid/python/README.txt
I dont think replacing with /home/me is the right thing to do here, the former simply implies wherever the user installed it rather than a specific directory and seems the more appropriate. Replacing with 0.8 also isnt actually all that helppful in my view, and will probably only lead to it being out of date at some point in future, so I would be inclined to leave that alone too. Robbie On 22 November 2010 16:38, wrote: > Author: jonathan > Date: Mon Nov 22 16:38:34 2010 > New Revision: 1037771 > > URL: http://svn.apache.org/viewvc?rev=1037771&view=rev > Log: > Corrected instructions for running Python clients - now matches 0.8 > distribution. > > Modified: > qpid/trunk/qpid/python/README.txt > > Modified: qpid/trunk/qpid/python/README.txt > URL: > http://svn.apache.org/viewvc/qpid/trunk/qpid/python/README.txt?rev=1037771&r1=1037770&r2=1037771&view=diff > == > --- qpid/trunk/qpid/python/README.txt (original) > +++ qpid/trunk/qpid/python/README.txt Mon Nov 22 16:38:34 2010 > @@ -1,24 +1,23 @@ > -= INSTALLATION = > += GETTING STARTED = > > -Extract the release archive into a directory of your choice and set > -your PYTHONPATH accordingly: > +1. Make sure the Qpid Python client libraries are on your PYTHONPATH: > > - tar -xzf qpid-python-.tar.gz -C > - export PYTHONPATH=/qpid-/python > +$ export PYTHONPATH=/home/me/qpid-0.8/python > > -= GETTING STARTED = > +2. Make sure a broker is running > > -The python client includes a simple hello-world example that publishes > -and consumes a message: > +3. Run the 'hello' example from qpid-0.8/python/examples/api: > + > +$ ./hello > +Hello world! > > - cp /qpid-/python/hello-world . > - ./hello-world > > = EXAMPLES = > > -More comprehensive examples can be found here: > +The examples/api directory contains several examples. > + > +Read examples/README.txt for further details on these examples. > > - cd /qpid-/python/examples > > = RUNNING THE TESTS = > > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:commits-subscr...@qpid.apache.org > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r1037771 - /qpid/trunk/qpid/python/README.txt
On 22 November 2010 16:51, Robbie Gemmell wrote:
> I dont think replacing with /home/me is the right
> thing to do here, the former simply implies wherever the user
> installed it rather than a specific directory and seems the more
> appropriate. Replacing with 0.8 also isnt actually all that
> helppful in my view, and will probably only lead to it being out of
> date at some point in future, so I would be inclined to leave that
> alone too.
>
> Robbie
Yes, I'd rather see versions and directories as placeholders, as in
the original, and I would also have expected the command to be
something like:
$ export PYTHONPATH=${PYTHONPATH}:/qpid-/python
Since the user may already have PYTHONPATH entries set.
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Updated: (QPID-2914) address parser doesn't recognize None
Hi Rafael, Im happy to include it, please merge it across to the branch. I had missed the commit on trunk and simply bumped it out to 0.9 because it looked like it had just been mis-tagged; there isnt any indication from looking at the JIRA that it has been worked on :) Robbie On 22 November 2010 12:52, Rafael Schloming wrote: > Is it too late to get this onto the RC branch for 0.8? The fix is on trunk > and fairly isolated. It just needs to be merged over. > > --Rafael > > On 11/22/2010 07:39 AM, Robbie Gemmell (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Robbie Gemmell updated QPID-2914: >> - >> >> Fix Version/s: (was: 0.8) >> 0.9 >> >>> address parser doesn't recognize None >>> - >>> >>> Key: QPID-2914 >>> URL: https://issues.apache.org/jira/browse/QPID-2914 >>> Project: Qpid >>> Issue Type: Bug >>> Components: Python Client >>> Reporter: Rafael H. Schloming >>> Assignee: Rafael H. Schloming >>> Fix For: 0.9 >>> >>> >>> The address parser treats None as an ID rather than as a special token. >> > > > - > 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: svn commit: r1037771 - /qpid/trunk/qpid/python/README.txt
By the time someone reads this README, they have already extracted the archive. I think what we really want to do is tell them to set it to the place they have extracted it to. Perhaps /path/to instead of /home/me? I actually prefer 0.8 instead of . I don't think we have ever had two consecutive versions where these instructions worked without change, someone has to review them each time anyway. If there's a fixed release number, it makes it that much more obvious that we need to do this. Jonathan On 11/22/2010 11:51 AM, Robbie Gemmell wrote: I dont think replacing with /home/me is the right thing to do here, the former simply implies wherever the user installed it rather than a specific directory and seems the more appropriate. Replacing with 0.8 also isnt actually all that helppful in my view, and will probably only lead to it being out of date at some point in future, so I would be inclined to leave that alone too. Robbie On 22 November 2010 16:38, wrote: Author: jonathan Date: Mon Nov 22 16:38:34 2010 New Revision: 1037771 URL: http://svn.apache.org/viewvc?rev=1037771&view=rev Log: Corrected instructions for running Python clients - now matches 0.8 distribution. Modified: qpid/trunk/qpid/python/README.txt Modified: qpid/trunk/qpid/python/README.txt URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/python/README.txt?rev=1037771&r1=1037770&r2=1037771&view=diff == --- qpid/trunk/qpid/python/README.txt (original) +++ qpid/trunk/qpid/python/README.txt Mon Nov 22 16:38:34 2010 @@ -1,24 +1,23 @@ -= INSTALLATION = += GETTING STARTED = -Extract the release archive into a directory of your choice and set -your PYTHONPATH accordingly: +1. Make sure the Qpid Python client libraries are on your PYTHONPATH: - tar -xzf qpid-python-.tar.gz -C - export PYTHONPATH=/qpid-/python +$ export PYTHONPATH=/home/me/qpid-0.8/python -= GETTING STARTED = +2. Make sure a broker is running -The python client includes a simple hello-world example that publishes -and consumes a message: +3. Run the 'hello' example from qpid-0.8/python/examples/api: + +$ ./hello +Hello world! - cp/qpid-/python/hello-world . - ./hello-world = EXAMPLES = -More comprehensive examples can be found here: +The examples/api directory contains several examples. + +Read examples/README.txt for further details on these examples. - cd/qpid-/python/examples = RUNNING THE TESTS = - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - 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: svn commit: r1037771 - /qpid/trunk/qpid/python/README.txt
On 22 November 2010 17:04, Jonathan Robie wrote: > By the time someone reads this README, they have already extracted the > archive. I think what we really want to do is tell them to set it to the > place they have extracted it to. > > Perhaps /path/to instead of /home/me? > > I actually prefer 0.8 instead of . I don't think we have ever had > two consecutive versions where these instructions worked without change, > someone has to review them each time anyway. If there's a fixed release > number, it makes it that much more obvious that we need to do this. I still think using a placeholder, either or even another environment variable, would be clearer. Also, I think we should aim for documentation that works now, but with the intention that it does *NOT* need changed every release and will, rather, continue working... Andrew. -- -- andrew d kennedy ? edinburgh : +44 7941 197 134 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: How easy is it to get Qpid going ?
On Mon, Nov 22, 2010 at 11:09 AM, Rajith Attapattu wrote: > Hi All, > > Based on the questions asked on our user list and feedback from customers > etc.. it seems that we have plenty of room to improve when it comes to ease > of use and documentation. > Ease of use is one that directly impacts the first impression about any new > product. > > I firmly believe this is something that needs to be one of the top > priorities (if not the top most) for our next release. > Perhaps it's time for us to take a step back and see if, > > 1) Have we packaged our products in a way that is useful for our target > users ? > Given that we have products written in multiple languages and targetted at different Operating systems perhaps pre-compiled individual components might not be the most optimal. Therefore downloading individual components doesn't really make sense as you need brokers, clients, examples and management tools, documentation to get a good all round experience. Instead we should probably ship a single source tree with some sort of script that will build the brokers, clients, examples and management tools and install the binaries to a particular location. Easier said than done, but I believe several folks have expressed their desire about taking this direction. > 2) How easy is it for folks to download an install our products ? > If we can achieve the above, I think it will go a long way in achieving this goal. > 3) How easy is it for people to run the examples and get it going? > Again, if we can get the above going, then it makes it very easy for folks to run the examples, preferably against both brokers. > 4) Have we organized our documentation properly? > I think we are on the right direction here. The new website and the svn based documentation is a big improvement. We just need to ensure we continue to do so. > 5) Have we got enough documentation to cover atleast the basic aspects? > I think we do this to a reasonable extent with the new "programming with apache qpid" document. However there are some gaps that exist and we need to ensure we fill them. > 6) Have we got enough documentation to cover the topics that people are > interested once they get the basics going? > I think the new documentation structure lacks this kinda of documentation. > 7) Are we releasing frequently enough for users to rely on us to ensure > that critical bugs are fixed ? > No ! - ThankfullyJustin has volunteered some time (as per his email to the list) to get frequent releases. At the minimum we need to do two major releases and two minor releases per year. > 8) Do we as a project have a process that defines how we handle a critical > issue after a release ? > I don't believe we have such a process at all. We need to first get into the habit of getting frequent releases and then see how we can do this sort of emergency fixes. > I am positive that our community (both developers and end users) has a lot > of good ideas. > I am quite keen on hearing suggestions/comments about the above topics. > I will start by replying to my email with what I think about the above > questions :) > > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
Re: How easy is it to get Qpid going ?
I like Rajith's idea of having one source distribution rather than a larger number of distributions that seem to go out without much testing. In RC2, most of the clients won't work if you just follow the instructions, the Python tools that we use in the programming guide aren't available as a separate distribution, the Java client had a README for the Java broker, etc. I like the convenience of downloading individual components, but only if they really work. Most of us work directly with the source tree, so we know that works. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: How easy is it to get Qpid going ?
On 11/22/2010 02:15 PM, Jonathan Robie wrote: Most of us work directly with the source tree, so we know that works. We also need to make the source tree more accessible. The new top-level README.txt at least identifies which components can be found in the source tree, and points to their README.txt files. If we continue the path top-down so that each component clearly says how to build it, and gives some overview, that should help a great deal. And I don't think that would take that much work. But the people responsible for each component should do that. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2914) address parser doesn't recognize None
[ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2914: - Affects Version/s: 0.7 Fix Version/s: (was: 0.9) 0.8 > address parser doesn't recognize None > - > > Key: QPID-2914 > URL: https://issues.apache.org/jira/browse/QPID-2914 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.7 >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.8 > > > The address parser treats None as an ID rather than as a special token. -- 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
[jira] Assigned: (QPID-2914) address parser doesn't recognize None
[ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2914: Assignee: Robbie Gemmell (was: Rafael H. Schloming) > address parser doesn't recognize None > - > > Key: QPID-2914 > URL: https://issues.apache.org/jira/browse/QPID-2914 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.7 >Reporter: Rafael H. Schloming >Assignee: Robbie Gemmell > Fix For: 0.8 > > > The address parser treats None as an ID rather than as a special token. -- 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
[jira] Commented: (QPID-2914) address parser doesn't recognize None
[ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934583#action_12934583 ] Robbie Gemmell commented on QPID-2914: -- Updating JIRA to reflect that Rafael has fixed this on trunk and merged it to the 0.8-release-candidates branch. > address parser doesn't recognize None > - > > Key: QPID-2914 > URL: https://issues.apache.org/jira/browse/QPID-2914 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.7 >Reporter: Rafael H. Schloming >Assignee: Robbie Gemmell > Fix For: 0.8 > > > The address parser treats None as an ID rather than as a special token. -- 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
[jira] Assigned: (QPID-2914) address parser doesn't recognize None
[ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2914: Assignee: Rafael H. Schloming (was: Robbie Gemmell) > address parser doesn't recognize None > - > > Key: QPID-2914 > URL: https://issues.apache.org/jira/browse/QPID-2914 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.7 >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.8 > > > The address parser treats None as an ID rather than as a special token. -- 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
[jira] Updated: (QPID-2914) address parser doesn't recognize None
[ https://issues.apache.org/jira/browse/QPID-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2914: - Status: Ready To Review (was: In Progress) > address parser doesn't recognize None > - > > Key: QPID-2914 > URL: https://issues.apache.org/jira/browse/QPID-2914 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.7 >Reporter: Rafael H. Schloming >Assignee: Robbie Gemmell > Fix For: 0.8 > > > The address parser treats None as an ID rather than as a special token. -- 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
[jira] Updated: (QPID-2947) use a newer sl4j-api release to allow the Java client binary convenience package to be used out-of-the-box
[ https://issues.apache.org/jira/browse/QPID-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2947: - Affects Version/s: (was: 0.8) 0.7 Fix Version/s: (was: 0.9) 0.8 Merged into 0.8 > use a newer sl4j-api release to allow the Java client binary convenience > package to be used out-of-the-box > -- > > Key: QPID-2947 > URL: https://issues.apache.org/jira/browse/QPID-2947 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.8 > > > New versions of slf4j-api do not throw an exception if no binding is provided > to a logging configuration, instead outputting a warning and defaulting to No > Op logging. This would allow the Java client to be used of the box without > forcing users to download a binding by themselves before being able to start > using the client (eg to run the examples). -- 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
Seeking information about working in "Starter" issues
Hi All, Good Day. I have downloaded the qpid 0.5 cpp src. I want to work on the *starter issue qpid-1402*. But I need some guidelines. That is why I need some help from you. 1. Do I need to get this issue assigned on my name before starting to work? If so, how do I acquire the permission? 2. I have downloaded the qpid 0.5 src folder. How do I understand if this version has this issue resolved or not? I am new here. So, I will be really grateful for any kind of help. Sincerely, Zafar Ahmed
Re: How easy is it to get Qpid going ?
I'd like to contribute a picture or two. Please comment on the current attachement. I'm trying to show how the parts relate to each other. I'm most familiar with the Cpp block so I'm most sure of what's going on in that part. My understandings are: 1. The Java stack goes end to end with no support required from Cpp. 2. WCF uses xarm (transaction resource manager) and the client, no messaging. 3. Python and Ruby QMF clients use the C++ QMF binding. 4. Python, Ruby, and .NET QPID clients use the C++ QPID binding. 5. Top level DOTNET client uses nothing from Cpp and is being deprecated. 6. Top level Python client uses nothing from Cpp but still works. It is probably not as great a choice as the Python Qpid binding for performance reasons. It should be kept as a/the reference implementation. 7. Top level Ruby client is being deprecated. I could use help showing relationships inside the Java box. I think that if this one picture were broken into maybe five with each showing different levels of detail it would be useful. Regards, Chuck - "Jonathan Robie" wrote: > From: "Jonathan Robie" > To: dev@qpid.apache.org > Sent: Monday, November 22, 2010 2:27:35 PM GMT -05:00 US/Canada Eastern > Subject: Re: How easy is it to get Qpid going ? > > On 11/22/2010 02:15 PM, Jonathan Robie wrote: > > > Most of us work directly with the source tree, so we know that > works. > > We also need to make the source tree more accessible. The new > top-level > README.txt at least identifies which components can be found in the > source tree, and points to their README.txt files. If we continue the > > path top-down so that each component clearly says how to build it, and > > gives some overview, that should help a great deal. > > And I don't think that would take that much work. But the people > responsible for each component should do that. > > Jonathan > > - > 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: How easy is it to get Qpid going ?
oops, no attachment. http://people.apache.org/~chug/QPID-0.8-Component-Architecture.pdf -C - "Chuck Rolke" wrote: > From: "Chuck Rolke" > To: dev@qpid.apache.org > Sent: Monday, November 22, 2010 5:21:17 PM GMT -05:00 US/Canada Eastern > Subject: Re: How easy is it to get Qpid going ? > > I'd like to contribute a picture or two. Please comment on the current > attachement. > > I'm trying to show how the parts relate to each other. I'm most > familiar with > the Cpp block so I'm most sure of what's going on in that part. > > My understandings are: > 1. The Java stack goes end to end with no support required from Cpp. > > 2. WCF uses xarm (transaction resource manager) and the client, no > messaging. > > 3. Python and Ruby QMF clients use the C++ QMF binding. > > 4. Python, Ruby, and .NET QPID clients use the C++ QPID binding. > > 5. Top level DOTNET client uses nothing from Cpp and is being > deprecated. > > 6. Top level Python client uses nothing from Cpp but still works. >It is probably not as great a choice as the Python Qpid binding > for >performance reasons. It should be kept as a/the reference > implementation. > > 7. Top level Ruby client is being deprecated. > > I could use help showing relationships inside the Java box. > > I think that if this one picture were broken into maybe five with each > showing > different levels of detail it would be useful. > > Regards, > Chuck > > - "Jonathan Robie" wrote: > > > From: "Jonathan Robie" > > To: dev@qpid.apache.org > > Sent: Monday, November 22, 2010 2:27:35 PM GMT -05:00 US/Canada > Eastern > > Subject: Re: How easy is it to get Qpid going ? > > > > On 11/22/2010 02:15 PM, Jonathan Robie wrote: > > > > > Most of us work directly with the source tree, so we know that > > works. > > > > We also need to make the source tree more accessible. The new > > top-level > > README.txt at least identifies which components can be found in the > > > source tree, and points to their README.txt files. If we continue > the > > > > path top-down so that each component clearly says how to build it, > and > > > > gives some overview, that should help a great deal. > > > > And I don't think that would take that much work. But the people > > responsible for each component should do that. > > > > Jonathan > > > > > - > > 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 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: How easy is it to get Qpid going ?
Yes, this is helpful. I've also tried to identify the "big picture" components in the new qpid/README.txt. Perhaps we should check in your PDF and point to it from qpid/README.txt? And if anyone wants to improve qpid/README.txt, please feel free! Jonathan On 11/22/2010 05:30 PM, Chuck Rolke wrote: oops, no attachment. http://people.apache.org/~chug/QPID-0.8-Component-Architecture.pdf -C - "Chuck Rolke" wrote: From: "Chuck Rolke" To: dev@qpid.apache.org Sent: Monday, November 22, 2010 5:21:17 PM GMT -05:00 US/Canada Eastern Subject: Re: How easy is it to get Qpid going ? I'd like to contribute a picture or two. Please comment on the current attachement. I'm trying to show how the parts relate to each other. I'm most familiar with the Cpp block so I'm most sure of what's going on in that part. My understandings are: 1. The Java stack goes end to end with no support required from Cpp. 2. WCF uses xarm (transaction resource manager) and the client, no messaging. 3. Python and Ruby QMF clients use the C++ QMF binding. 4. Python, Ruby, and .NET QPID clients use the C++ QPID binding. 5. Top level DOTNET client uses nothing from Cpp and is being deprecated. 6. Top level Python client uses nothing from Cpp but still works. It is probably not as great a choice as the Python Qpid binding for performance reasons. It should be kept as a/the reference implementation. 7. Top level Ruby client is being deprecated. I could use help showing relationships inside the Java box. I think that if this one picture were broken into maybe five with each showing different levels of detail it would be useful. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: How easy is it to get Qpid going ?
On 22 Nov 2010, at 18:00, Rajith Attapattu wrote: On Mon, Nov 22, 2010 at 11:09 AM, Rajith Attapattu wrote: Hi All, Based on the questions asked on our user list and feedback from customers etc.. it seems that we have plenty of room to improve when it comes to ease of use and documentation. Ease of use is one that directly impacts the first impression about any new product. All, I pretty much agree with these points, although with some reservations about the one-size-fits-all packaging proposal... I firmly believe this is something that needs to be one of the top priorities (if not the top most) for our next release. Perhaps it's time for us to take a step back and see if, 1) Have we packaged our products in a way that is useful for our target users ? Given that we have products written in multiple languages and targetted at different Operating systems perhaps pre-compiled individual components might not be the most optimal. Therefore downloading individual components doesn't really make sense as you need brokers, clients, examples and management tools, documentation to get a good all round experience. Instead we should probably ship a single source tree with some sort of script that will build the brokers, clients, examples and management tools and install the binaries to a particular location. Easier said than done, but I believe several folks have expressed their desire about taking this direction. Goo...? I'm not sure about this. That doesn't seem like the usual model for enterprise software distribution. 1. I agree that providing a full, DIY source bundle is something that should definitely be provided, but in addition to other downloads. I don't see why both models can't coexist? 2. It should be alongside componentised or modularised binary downloads. The installable artifacts are the brokers and the management console/command line tools, which should be available as platform specific binaries, installable packages of various kinds, and as a DIY source tarball, for Java and C++. 3. The second type of artifacts are the developer components, the client libraries for various languages. These should be available as components that can be installed into repositories or development environments, such as Maven POM files or OSGi modules. The client library for each language or environment should include the runtime components, which may need to be installable, as well as providing the artifacts that can be packaged with software being developed. These three types of artifact multiplied by the available execution platforms, languages, runtimes and environments (which includes DIY or source tarball format) gives a formidable number of downloadable artifacts, which must be carefully documented in order not to confuse end users. For instance for the C++ broker, in addition to a DIY source download there could be x86 RPMs, x86_64 RPMs, Solaris 10 SPARC packages, Win32 MSI installer, Debian and other Linux packages, again in x86 and x86_64 variants, and so on. I suspect a multi-level approach here is useful, from 'Beginner' to 'Advanced' levels, with appropriate artifacts provided. We obviously need to decide *what* we support and stick to it as well as keeping everything as simple as possible. Perhaps the Tomcat site could serve as a model, since it also provides Java and cross platform Unix and Windows code as both binaries *and* source. See here: http://tomcat.apache.org/download-70.cgi 2) How easy is it for folks to download an install our products ? If we can achieve the above, I think it will go a long way in achieving this goal. Each download needs suitable and useful documentation to help the end user get it running as fast as possible, possibly we should provide a set of configuration files for the brokers as an additional set of downloads or as part of a HOWTO series on the documentation. This is not currently the case. For instance, I expect the site front page, where it mentions python, to be clicky and take me to a page that tells me about python support in Qpid, or lets me download the python client. Currently it is not obvious what and this is a big fail. 3) How easy is it for people to run the examples and get it going? Again, if we can get the above going, then it makes it very easy for folks to run the examples, preferably against both brokers. See above, +1. 4) Have we organized our documentation properly? I think we are on the right direction here. The new website and the svn based documentation is a big improvement. We just need to ensure we continue to do so. The idea has been floated of making a direct link from SVN to the website. basically, we need to ensure there is a *stable* set of pages that can be linked to and *added* to, as new features and components are developed, and FAQs are answered or bugs fixed. This used to be
Fwd: Your OS License Request
All, I now have a copy of the JetBrains PyCharm license for the Qpid project, so please mail me if you would like a copy. Cheers, Andrew. -- -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ; -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7941 197 134 ; Begin forwarded message: From: "JetBrains - Julia Kuznetsova" Date: 17 November 2010 16:13:32 GMT To: Subject: Your OS License Request Reply-To: X-Mailer: Microsoft Office Outlook 11 Hello Andrew, We have approved your request and issued a free OS license of PyCharm to your project. The license key is multi-user and given for the whole project, so it’d be great if you could let other developers know that the project’s received a free OS license. Thanks! Kind regards, Julia Kuznetsova Community Support Coordinator JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Made changes for RC3? Please verify them by 6pm GMT, 23rd Nov...
I have just spent some time making updates for inclusion in 0.8 RC3, and also merging across changes from trunk by others that I believe are intended for inclusion in RC3 but have thus far not been merged. The 0.8-release-candidates branch as it stands now (r1037942) is what RC3 will currently be produced from. I will now be producing RC3 tomorrow, Tuesday 23rd, at 6pm GMT. If you have made changes you expect to be included and didn't already merge them across yourself, please check that I have caught them. If I missed anything or you make other changes for consideration, please email me the trunk commit revisions so I can consider them. The current list of changes from RC2 stands at: - Updates to various RELEASE_NOTES files - Updates to/addition of various README files - Remove a few redundant or out of date scripts/README files from Java tree - Update to avoid error in the cpp hello_xml example - Make the ruby hello example executable - QPID-2914: python address parser doesn't recognize None - QPID-2947: update slf4j to allow using the java client package out-of-the-box - QPID-2948: Generated API docs have extraneous macro names in method signatures - QPID-2950: stop incorrectly logging an expected exception during DerbyMessageStore closure Thanks, Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: JMS Client reconnect
I'm currently running a cluster, and I do see it is automatically failing over to other nodes in the cluster. But I am trying to test the case where all brokers in the cluster is down ( or in other words the cluster is down ), I'm hoping both the producer and the client won't just die but keep on attempting to reconnect until the cluster is backup, so I'm trying to get the exception from the Javax.jms.connection so I can start the retry logic. You mentioned a connection listener, are you referring to ExceptionListener? http://download.oracle.com/javaee/1.4/api/javax/jms/ExceptionListener.html And also I wonder if there is any best practices for reconnecting when there are multiple producers in different threads all sharing one connection but multiple sessions? Tim On Mon, Nov 22, 2010 at 7:46 AM, Rajith Attapattu wrote: > On Thu, Nov 18, 2010 at 5:10 PM, Tim Chen wrote: > > > Hi all, > > > > I wonder what's the best way to handle reconnect to the broker when > broker > > is unavailable (network is down / broker crashed, etc) using Java JMS > > client > > to C++ broker? > > > > Are you running a cluster or is it a bunch of standalone brokers ? > > > > > Currently when using the JMS client when the broker is killed, a runtime > > exception ( ConnectionException ) is thrown internally in qpid and I > don't > > see a way I can get this exception. > > > > > The Qpid JMS client supports transparent failover if configured properly. > > If you are running a cluster then > --- > For c++ broker you can set the failover method to "failover_exchange" and > the client will transparently retrieve the available brokers from the > cluster and will connect to one of them if the current broker fails. > Ex amqp://guest:gu...@clientid > /testpath?brokerlist='tcp://localhost:5672'&failover='failover_exchange' > > If you are running a set of standalone brokers > --- > You can set the failover method to round robin an provide a list of > brokers. > Ex amqp://guest:gu...@clientid > > /testpath?brokerlist='tcp://host1:5672;tcp://host2:5672..;tcp://hostn:5672'&failover='roundrobin' > > > Also if all attempts are unsuccessful (i.e total cluster failure or all > brokers in the list are down) then it will throw an exception if there is a > connection listener set. > It will not notify a connection exception If and only if it can connect to > another broker in the cluster (or the list of brokers if provided with > failover=roundrobin). > i.e it will not notify any intermediate failures. > > > > > > I tried to add a check each time it sends a message if the broker > > connection > > is closed ( AMQConnection.isClosed() ) to re-attempt to reconnect. > > > > However, I see that if the broker is disconnected not via > > AMQConnection.close(), the state is never set to CLOSED and still set as > > OPEN. > > > > Please stick to the standard JMS interfaces as internal classes like > AMQConnection are subject change from release to release. > > > > > > From reading this: > > > > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/pdf/Programming_in_Apache_Qpid/Red_Hat_Enterprise_MRG-1.3-Programming_in_Apache_Qpid-en-US.pdf > > > > It has reconnect flags on using Python and C++ clients to automatically > > reconnect if connection is lost. > > > > But I wonder what's the best way to do this in JMS client? > > > > Thanks, > > > > Tim > > > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ >
