[jira] Updated: (QPID-2953) Qpid Cpp Messaging .NET Binding does not include unit tests

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Rafael Schloming
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

2010-11-22 Thread Ted Ross (JIRA)

[ 
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

2010-11-22 Thread Andrew Kennedy (JIRA)

[ 
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

2010-11-22 Thread Carl Trieloff



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

2010-11-22 Thread Jonathan Robie
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

2010-11-22 Thread Robbie Gemmell
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

2010-11-22 Thread Rajith Attapattu
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

2010-11-22 Thread michael j. goulish (JIRA)

 [ 
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

2010-11-22 Thread michael j. goulish (JIRA)

 [ 
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

2010-11-22 Thread michael j. goulish (JIRA)

 [ 
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

2010-11-22 Thread michael j. goulish (JIRA)

 [ 
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

2010-11-22 Thread michael j. goulish (JIRA)

 [ 
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

2010-11-22 Thread michael j. goulish (JIRA)

 [ 
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."

2010-11-22 Thread Alan Conway (JIRA)
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."

2010-11-22 Thread Alan Conway (JIRA)

 [ 
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 ?

2010-11-22 Thread Rajith Attapattu
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."

2010-11-22 Thread Alan Conway (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell
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

2010-11-22 Thread Andrew Kennedy
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

2010-11-22 Thread Robbie Gemmell
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

2010-11-22 Thread Jonathan Robie
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

2010-11-22 Thread Andrew Kennedy
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 ?

2010-11-22 Thread Rajith Attapattu
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 ?

2010-11-22 Thread Jonathan Robie
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 ?

2010-11-22 Thread Jonathan Robie

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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

[ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Robbie Gemmell (JIRA)

 [ 
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

2010-11-22 Thread Zafar Ahmed
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 ?

2010-11-22 Thread Chuck Rolke
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 ?

2010-11-22 Thread Chuck Rolke
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 ?

2010-11-22 Thread Jonathan Robie

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 ?

2010-11-22 Thread Andrew Kennedy

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

2010-11-22 Thread Andrew Kennedy

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...

2010-11-22 Thread Robbie Gemmell
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

2010-11-22 Thread Tim Chen
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/
>