Re: 0.12 release update - upcoming dates

2011-06-20 Thread Justin Ross
Hi, Steve.  Sorry for the late reply.  I'm close to cutting the alpha now, and 
it doesn't look like your change has landed.  I took a look at the jira, 
however, and it looks to me like something we could accept up to beta.

Justin

- Original Message -
From: Steve Huston shus...@riverace.com
To: dev@qpid.apache.org
Sent: Thursday, June 16, 2011 7:45:12 PM
Subject: RE: 0.12 release update - upcoming dates

Justin, I'm trying to land the fix for QPID-3256 - there are a few
review comments outstanding, but so far nothing major. The original
problem reporter has already verified the patch fixes the original
problem.

Ok to get this in tomorrow? If needed I can try to get it in today but
I'd rather work the review comments with more deliberation.

Thanks,
-Steve

--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com


 -Original Message-
 From: Justin Ross [mailto:jr...@redhat.com] 
 Sent: Tuesday, June 14, 2011 10:47 AM
 To: dev@qpid.apache.org
 Subject: Re: 0.12 release update - upcoming dates
 
 
 I agree, and that's why I prefer to set the deadlines to the 
 middle of the week.  That way if we slip a little, there's 
 still a chance we'll get it that week and not the next.
 
 Rajith (or anyone else facing a similar problem), are the 
 changes you'd like to see in 0.12 looking like they will land 
 by end of day Wednesday?  Just so I can determine when we can 
 accept it, what's the new feature and what is its current status?
 
 Justin
 
 - Original Message -
 From: Aidan Skinner aidan.skin...@gmail.com
 To: dev@qpid.apache.org
 Sent: Friday, June 3, 2011 1:43:45 AM
 Subject: Re: 0.12 release update - upcoming dates
 
 I'm really only passing through qpid-dev, so feel free to 
 ignore me, but IME Friday deadlines turn into Monday 
 deadlines turn into Wednesday the week after deadlines all too easily.
 
 - Aidan
 
 On Thu, Jun 2, 2011 at 2:21 PM, Rajith Attapattu 
 rajit...@gmail.com wrote:
  Justin,
 
  Wondering if you could move the beta date to 17th of June (friday) 
  instead of the 15th?
 
  Regards,
 
  Rajith
 
  On Tue, May 31, 2011 at 5:19 PM, Justin Ross 
 jr...@redhat.com wrote:
 
  Hi, folks.  Here are some of the upcoming dates for the 
 0.12 release 
  of Qpid.
 
   - 3 March - 0.12 trunk opened
   - 15 June - 0.12 alpha (in a little over 2 weeks)
   - 28 June - 0.12 beta
   - 27 July - Target date for the final 0.12 release candidate
 
  The alpha date is the deadline for landing major features.  Said 
  features must be functionally complete, with all 
 distribution-related 
  integration complete.
 
  After the alpha, we may still be able to accept a new 
 feature, but it 
  must be something (a) quite small or (b) isolated from the other 
  code. In addition, it must not change the existing distribution 
  artifacts in any significant way.
 
  With the beta, we will create the 0.12 release branch, and 0.14 
  development can then begin on trunk.
 
  The release page[1] has links to the jiras for 0.12 and an 
 overview 
  of the schedule.
 
  Thanks!
  Justin
 
  ---
  [1] https://cwiki.apache.org/confluence/display/qpid/0.12+Release
 
  
 -
  Apache Qpid - AMQP Messaging Implementation
  Project:      http://qpid.apache.org
  Use/Interact: mailto:dev-subscr...@qpid.apache.org
 
 
 
 
 
 
 -- 
 Apache Qpid - AMQP, JMS, other messaging love 
 http://qpid.apache.org A witty saying proves nothing - Voltaire
 
 -
 Apache Qpid - AMQP Messaging Implementation
 Project:  http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org
 
 
 -
 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



[jira] [Updated] (QPID-3307) ClassNotfound Exception when using Qpid java client in Complex classloading Environments.

2011-06-20 Thread Charith Dhanushka Wickramarachchi (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Charith Dhanushka Wickramarachchi updated QPID-3307:


Attachment: QPID-3307_patch_unit_test.txt

Hi , 

I'm attaching an unit test case which will send receive an Object Message which 
have a custom Serializable Type inside.In that case the ObjectInputStream i 
have provided will be used. To re-create the exact class loading scenario I'll 
have to find a way to simulate that kind of class loading environment within 
the Unit test. I'll have to think through it on how to implement that.

thanks,
Charith


 ClassNotfound Exception when using Qpid java client in Complex classloading 
 Environments.  
 ---

 Key: QPID-3307
 URL: https://issues.apache.org/jira/browse/QPID-3307
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Reporter: Charith Dhanushka Wickramarachchi
Priority: Critical
 Attachments: QPID-3307_patch.txt, QPID-3307_patch.txt, 
 QPID-3307_patch.txt, QPID-3307_patch_unit_test.txt


 Hi ,
 When we are using qpid client to receive JMSObject in complex class loading 
 environments like web application containers/Osgi environments .There is a 
 scenario where this issues comes. 
 Scenario. 
 In a web application container normally they use a class loader per web app. 
 and if we have qpid client libs at the root classloader level this error can 
 come. The reason for this is Serializable  Object types that are used inside 
 the web app are not visible to the class loader that loads the JMSObject 
 message and unmarshall it.
 thanks,
 Charith

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



[jira] [Created] (QPID-3312) Console throws unhandled exception when the broker shuts down/restarts

2011-06-20 Thread Ricardo Pereira moura (JIRA)
Console throws unhandled exception when the broker shuts down/restarts
--

 Key: QPID-3312
 URL: https://issues.apache.org/jira/browse/QPID-3312
 Project: Qpid
  Issue Type: Bug
  Components: Dot Net Client
Affects Versions: 0.10
 Environment: Windows 7
Reporter: Ricardo Pereira moura
 Fix For: 0.10


When the broker shuts down or restarts the dotnet Qpid Console (version 0.10) 
throws an unhandled exception:

Log Name:  Application
Source:.NET Runtime
Date:  19-06-2011 13:23:26
Event ID:  1026
Task Category: None
Level: Error
Keywords:  Classic
User:  N/A
Computer:  XXX
Description:
Application: XXX.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: org.apache.qpid.transport.SessionClosedException
Stack:
   at org.apache.qpid.transport.Session.Invoke(org.apache.qpid.transport.Method)
   at org.apache.qpid.transport.Invoker.MessageStop(System.String, 
org.apache.qpid.transport.Option[])
   at org.apache.qpid.console.Broker.Shutdown()
   at org.apache.qpid.console.Broker.Finalize()

Event Xml:
Event xmlns=http://schemas.microsoft.com/win/2004/08/events/event;
  System
Provider Name=.NET Runtime /
EventID Qualifiers=01026/EventID
Level2/Level
Task0/Task
Keywords0x80/Keywords
TimeCreated SystemTime=2011-06-19T12:23:26.0Z /
EventRecordID20215/EventRecordID
ChannelApplication/Channel
ComputerXXX/Computer
Security /
  /System
  EventData
DataApplication: XXX.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: org.apache.qpid.transport.SessionClosedException
Stack:
   at org.apache.qpid.transport.Session.Invoke(org.apache.qpid.transport.Method)
   at org.apache.qpid.transport.Invoker.MessageStop(System.String, 
org.apache.qpid.transport.Option[])
   at org.apache.qpid.console.Broker.Shutdown()
   at org.apache.qpid.console.Broker.Finalize()
/Data
  /EventData
/Event

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



RE: 0.12 release update - upcoming dates

2011-06-20 Thread Steve Huston
Ok, thanks Justin.

The review process picked up some problems and I understand Cliff Jansen
is working on these. For some odd reason I'm not seeing Cliff's review
updates though.

--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com


 -Original Message-
 From: Justin Ross [mailto:jr...@redhat.com] 
 Sent: Monday, June 20, 2011 4:38 AM
 To: dev@qpid.apache.org
 Subject: Re: 0.12 release update - upcoming dates
 
 
 Hi, Steve.  Sorry for the late reply.  I'm close to cutting 
 the alpha now, and it doesn't look like your change has 
 landed.  I took a look at the jira, however, and it looks to 
 me like something we could accept up to beta.
 
 Justin
 
 - Original Message -
 From: Steve Huston shus...@riverace.com
 To: dev@qpid.apache.org
 Sent: Thursday, June 16, 2011 7:45:12 PM
 Subject: RE: 0.12 release update - upcoming dates
 
 Justin, I'm trying to land the fix for QPID-3256 - there are 
 a few review comments outstanding, but so far nothing major. 
 The original problem reporter has already verified the patch 
 fixes the original problem.
 
 Ok to get this in tomorrow? If needed I can try to get it in 
 today but I'd rather work the review comments with more deliberation.
 
 Thanks,
 -Steve
 
 --
 Steve Huston, Riverace Corporation
 Total Lifecycle Support for Your Networked Applications 
 http://www.riverace.com
 
 
  -Original Message-
  From: Justin Ross [mailto:jr...@redhat.com]
  Sent: Tuesday, June 14, 2011 10:47 AM
  To: dev@qpid.apache.org
  Subject: Re: 0.12 release update - upcoming dates
  
  
  I agree, and that's why I prefer to set the deadlines to the
  middle of the week.  That way if we slip a little, there's 
  still a chance we'll get it that week and not the next.
  
  Rajith (or anyone else facing a similar problem), are the
  changes you'd like to see in 0.12 looking like they will land 
  by end of day Wednesday?  Just so I can determine when we can 
  accept it, what's the new feature and what is its current status?
  
  Justin
  
  - Original Message -
  From: Aidan Skinner aidan.skin...@gmail.com
  To: dev@qpid.apache.org
  Sent: Friday, June 3, 2011 1:43:45 AM
  Subject: Re: 0.12 release update - upcoming dates
  
  I'm really only passing through qpid-dev, so feel free to
  ignore me, but IME Friday deadlines turn into Monday 
  deadlines turn into Wednesday the week after deadlines all 
 too easily.
  
  - Aidan
  
  On Thu, Jun 2, 2011 at 2:21 PM, Rajith Attapattu
  rajit...@gmail.com wrote:
   Justin,
  
   Wondering if you could move the beta date to 17th of June (friday)
   instead of the 15th?
  
   Regards,
  
   Rajith
  
   On Tue, May 31, 2011 at 5:19 PM, Justin Ross
  jr...@redhat.com wrote:
  
   Hi, folks.  Here are some of the upcoming dates for the
  0.12 release
   of Qpid.
  
    - 3 March - 0.12 trunk opened
    - 15 June - 0.12 alpha (in a little over 2 weeks)
    - 28 June - 0.12 beta
    - 27 July - Target date for the final 0.12 release candidate
  
   The alpha date is the deadline for landing major features.  Said
   features must be functionally complete, with all 
  distribution-related
   integration complete.
  
   After the alpha, we may still be able to accept a new
  feature, but it
   must be something (a) quite small or (b) isolated from the other
   code. In addition, it must not change the existing distribution 
   artifacts in any significant way.
  
   With the beta, we will create the 0.12 release branch, and 0.14
   development can then begin on trunk.
  
   The release page[1] has links to the jiras for 0.12 and an
  overview
   of the schedule.
  
   Thanks!
   Justin
  
   ---
   [1] https://cwiki.apache.org/confluence/display/qpid/0.12+Release
  
   
  
 -
   Apache Qpid - AMQP Messaging Implementation
   Project:      http://qpid.apache.org
   Use/Interact: mailto:dev-subscr...@qpid.apache.org
  
  
  
  
  
  
  --
  Apache Qpid - AMQP, JMS, other messaging love 
  http://qpid.apache.org A witty saying proves nothing - Voltaire
  
  
 -
  Apache Qpid - AMQP Messaging Implementation
  Project:  http://qpid.apache.org
  Use/Interact: mailto:dev-subscr...@qpid.apache.org
  
  
  
 -
  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: 

[jira] [Resolved] (QPID-3129) cluster_tests.LongTests.test_failover hangs

2011-06-20 Thread Alan Conway (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved QPID-3129.
---

Resolution: Fixed

Fixed on trunk r1137657

 cluster_tests.LongTests.test_failover hangs 
 

 Key: QPID-3129
 URL: https://issues.apache.org/jira/browse/QPID-3129
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.9
Reporter: Alan Conway
Assignee: Alan Conway
Priority: Minor
 Fix For: 0.11


 The test cluster_tests.LongTests.test_failover hangs if run with duration of 
 a minute or more.
 To reproduce:
   make check TESTS=run_cluster_tests 
 CLUSTER_TESTS='cluster_tests.LongTests.test_failover -DDURATION=1'
 Should pass after about 1 minute, but hangs indefinitely.
 This is probably a test bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



Qpid python bindings for windows

2011-06-20 Thread Ovidiu Visan
Hi guys,

We need to stand up a windows proxy, in the cloud backend, so that the proxy 
can use local authentication to the booting instance.  We want to control the 
proxy via qpid/qmf, to pass commands down to it and get results back. For that 
we want to use Python, so the question is: are there any qpid bindings for 
python that would work in windows?

Thank you.

Ovi


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



Review Request: QPID-3265 Can't subscribe to headers exchange using address (rather than BURL)

2011-06-20 Thread rajith attapattu

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/937/
---

Review request for qpid.


Summary
---

The patch makes the following changes

1. AMQSession_0_10.java
   A default binding is only added if there are no explicit bindings specified 
via x-bindings

2. BasicMessageConsumer_0_10.java
   When the same destination (Topic) is used to create two different consumers 
the code creates a copy of the destination to ensure the second consumer gets 
it's own unique temp queue. When doing so we need to ensure we delete any 
bindings for the previous temp queue. If we don't remove old bindings and if 
there were no explicit bindings specified via x-bindings, then the second 
consumers queue will not be bound due to the logic mentioned in [1]. (Bcos the 
previous binding is treated as explicit bindings).

3. AddressHelper.java
   The second part of the JIRA covers a different bug - i.e x-binding specified 
in the link properties are not used if the node type if a queue.
I added code to read the x-bindings in link props if there are no 
x-bindings specified in the node props.

4. Modified test cases
1. To ensure that a default binding is not added when explicit bindings are 
specified.
2. To fix an existing test case that relied on a default binding even when 
x-bindings is specified.
(*) I still need to add (or modify an existing test case) to cover the case 
where x-bindings are specified in link props when the node type if a queue.


This addresses bug QPID-3265.
https://issues.apache.org/jira/browse/QPID-3265


Diffs
-

  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
 1137691 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java
 1137691 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/messaging/address/AddressHelper.java
 1137691 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/destination/AddressBasedDestinationTest.java
 1137691 

Diff: https://reviews.apache.org/r/937/diff


Testing
---

The use cases specified in the JIRA were manually tested in addition to the 
above mentioned automated test cases.


Thanks,

rajith



[jira] [Commented] (QPID-3265) Can't subscribe to headers exchange using address (rather than BURL)

2011-06-20 Thread jirapos...@reviews.apache.org (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052089#comment-13052089
 ] 

jirapos...@reviews.apache.org commented on QPID-3265:
-


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/937/
---

Review request for qpid.


Summary
---

The patch makes the following changes

1. AMQSession_0_10.java
   A default binding is only added if there are no explicit bindings specified 
via x-bindings

2. BasicMessageConsumer_0_10.java
   When the same destination (Topic) is used to create two different consumers 
the code creates a copy of the destination to ensure the second consumer gets 
it's own unique temp queue. When doing so we need to ensure we delete any 
bindings for the previous temp queue. If we don't remove old bindings and if 
there were no explicit bindings specified via x-bindings, then the second 
consumers queue will not be bound due to the logic mentioned in [1]. (Bcos the 
previous binding is treated as explicit bindings).

3. AddressHelper.java
   The second part of the JIRA covers a different bug - i.e x-binding specified 
in the link properties are not used if the node type if a queue.
I added code to read the x-bindings in link props if there are no 
x-bindings specified in the node props.

4. Modified test cases
1. To ensure that a default binding is not added when explicit bindings are 
specified.
2. To fix an existing test case that relied on a default binding even when 
x-bindings is specified.
(*) I still need to add (or modify an existing test case) to cover the case 
where x-bindings are specified in link props when the node type if a queue.


This addresses bug QPID-3265.
https://issues.apache.org/jira/browse/QPID-3265


Diffs
-

  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
 1137691 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java
 1137691 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/messaging/address/AddressHelper.java
 1137691 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/destination/AddressBasedDestinationTest.java
 1137691 

Diff: https://reviews.apache.org/r/937/diff


Testing
---

The use cases specified in the JIRA were manually tested in addition to the 
above mentioned automated test cases.


Thanks,

rajith



 Can't subscribe to headers exchange using address (rather than BURL)
 

 Key: QPID-3265
 URL: https://issues.apache.org/jira/browse/QPID-3265
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Affects Versions: 0.10
 Environment: java 0.10 client
Reporter: Gordon Sim
Assignee: Rajith Attapattu

 Creating a receiver for the following address works from python and c++, but 
 not from JMS (using drain example in each case):
   my-headers-exchange; 
 {link:{x-bindings:[{arguments:{'x-match':all,a:b,c:d}}]}}
 The problem with JMS seems to be that though it correctly interprets the 
 arguments and issues a bind with them in it, it issues another bind to the 
 exchange with no arguments that fails with an error.
 Also, the following also doesn't work:
   my-subscription-queue; {create:always, node:{x-declare:{auto-delete:True}}, 
 link:{x-bindings:[{queue:my-subscription-queue, exchange:my-headers-exchange, 
 arguments:{'x-match':all,a:b,c:d}}]}}
 Here the x-bindings in the link don't seem to get interpreted. However if 
 instead they are moved to the node, that works.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



[jira] [Commented] (QPID-3311) ConcurrentModificationException in java client during failover

2011-06-20 Thread Rajith Attapattu (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052096#comment-13052096
 ] 

Rajith Attapattu commented on QPID-3311:


The patch looks good to me.
I will commit this shortly.

 ConcurrentModificationException in java client during failover
 --

 Key: QPID-3311
 URL: https://issues.apache.org/jira/browse/QPID-3311
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Reporter: Siddhesh Poyarekar
 Attachments: TxSender.java, qpid-java-safe-remove-sessions.patch


 Description of problem:
 The java client removes transacted sessions during failover. This removal is
 not safe however, since it happens when the Hashmap of sessions is being
 iterated through. This occasionally results in a
 ConcurrentModificationException.
 How reproducible:
 Always
 Steps to Reproduce:
 1. Run attached program
 Actual results:
 ERROR [IoReceiver - localhost/127.0.0.1:5672]
 (AMQConnectionDelegate_0_10.java:281) - error during failover
 java.util.ConcurrentModificationException
  at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
  at java.util.HashMap$ValueIterator.next(HashMap.java:839)
  at org.apache.qpid.transport.Connection.resume(Connection.java:469)
  at
 org.apache.qpid.client.AMQConnectionDelegate_0_10.resubscribeSessions(AMQConnectionDelegate_0_10.java:221)
  at
 org.apache.qpid.client.AMQConnection.resubscribeSessions(AMQConnection.java:1207)
  at
 org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:274)
  at org.apache.qpid.transport.Connection.closed(Connection.java:561)
  at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:110)
  at
 org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:202)
  at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:150)
  at java.lang.Thread.run(Thread.java:636)
 ERROR [IoReceiver - localhost/127.0.0.1:5672]
 (AMQConnectionDelegate_0_10.java:293) - connection exception: conn:3749eb9f
 org.apache.qpid.transport.ConnectionException: connection aborted
  at org.apache.qpid.transport.Connection.closed(Connection.java:534)
  at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:110)
  at
 org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:202)
  at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:150)
  at java.lang.Thread.run(Thread.java:636)
 Expected results:
 Successful failover
 Additional info:
 Logging options (log4j.properties):
 log4j.rootLogger=debug, stdout, R
 log4j.appender.stdout=org.apache.log4j.ConsoleAppender
 log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
 # Pattern to output the caller's file name and line number.
 log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
 log4j.appender.R=org.apache.log4j.FileAppender
 log4j.appender.R.File=example.log
 log4j.appender.R.MaxFileSize=1KB
 # Keep one backup file
 log4j.appender.R.MaxBackupIndex=1
 log4j.appender.R.layout=org.apache.log4j.PatternLayout
 log4j.logger.org.apache=TRACE

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



Re: Review Request: QPID-3079: allow asynchronous completion of Message.Accept command (note: requires store interface changes).

2011-06-20 Thread Kenneth Giusti


 On 2011-06-17 13:19:13, Alan Conway wrote:
  Looking good, just a few suggestions.
  
  Note on testing: need to run store tests as well as qpidd tests.

Yes, both store and C++ broker unit tests are passing.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 116
  https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line116
 
  Static locals not thread safe, use a normal local variable.

Removed.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 125
  https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line125
 
  What happens in the case isRedundant() == true?

the D.R. is removed from the unacked list - this check has been moved to the 
caller.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 300
  https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line300
 
  Functions are too big to inline in .h, move to .cpp.

done.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 310
  https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line310
 
  Suggest a change here to make it more flexible and type safe:
  
  registerCallback(boost::functionvoid() f);
  
  You can package up all the details in boost::bind at the call site, 
  this class doesn't need to know. See comments below

Very nice - done.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.cpp, line 665
  https://reviews.apache.org/r/860/diff/2/?file=21214#file21214line665
 
  static local variables are not thread safe. Use a normal local variable 
  constructing an intrusive pointer is trivial.

done.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 804
  https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line804
 
  This doesn't need to be static, and you can avoid the casting. Just 
  write
  
  void dequeueDone() { cmd-complete(); }
  
  and see further comment at the call site below

done.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 966
  https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line966
 
  See comments above: this can now be
  
  
  async-registerCallback(boost::bind(AsyncMessageAcceptCmd::dequeueDone, 
  this))

done.


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 437
  https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line437
 
  Store the DequeueCompletion pointer on the PersistableMessage, avoid 
  this map lookup.

Sorry Alan, I'm being dense here - I don't understand.  Wouldn't the 
PersistableMessage still need a container for the DequeueCompletions, as there 
may be more than one dequeue pending for that message?  I'm thinking of fanout 
- same physical PersistableMessage shared among N queues.  There may be several 
different sessions dequeuing/accepting that message at the same time, right?  
How do we 'map' (heh) back from the P.M. to the sessions pending on the 
Message.Accept completion? 


 On 2011-06-17 13:19:13, Alan Conway wrote:
  /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.h, line 107
  https://reviews.apache.org/r/860/diff/2/?file=21210#file21210line107
 
  Why the change from dequeue to list?

Big performance improvement with qpid-cpp-benchmark by moving from a dequeue to 
a list.  I'm guessing because we delete entries from the middle of the list(?)


- Kenneth


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/860/#review859
---


On 2011-06-16 15:25:17, Kenneth Giusti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/860/
 ---
 
 (Updated 2011-06-16 15:25:17)
 
 
 Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
 
 
 Summary
 ---
 
 Modifies the broker's handling of Message.Accept to hold off the completion 
 of the command until all messages related to the accept have completed 
 dequeue.  This particularly applies to persistent messages, as the 
 store::dequeue() operation must complete before the message is considered 
 fully dequeued.
 
 Note this bugfix requires some changes to the broker's store module 
 interface:  previously, the store only identified the message when a dequeue 
 was completed.  This is not enough information - the queue from which is was 
 removed must also be identified (the message may be in the 

[jira] [Commented] (QPID-3079) message.accept command should be completed on a per-dequeue basis

2011-06-20 Thread jirapos...@reviews.apache.org (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052155#comment-13052155
 ] 

jirapos...@reviews.apache.org commented on QPID-3079:
-



bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   Looking good, just a few suggestions.
bq.   
bq.   Note on testing: need to run store tests as well as qpidd tests.

Yes, both store and C++ broker unit tests are passing.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 116
bq.   https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line116
bq.  
bq.   Static locals not thread safe, use a normal local variable.

Removed.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 125
bq.   https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line125
bq.  
bq.   What happens in the case isRedundant() == true?

the D.R. is removed from the unacked list - this check has been moved to the 
caller.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 300
bq.   https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line300
bq.  
bq.   Functions are too big to inline in .h, move to .cpp.

done.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 310
bq.   https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line310
bq.  
bq.   Suggest a change here to make it more flexible and type safe:
bq.   
bq.   registerCallback(boost::functionvoid() f);
bq.   
bq.   You can package up all the details in boost::bind at the call site, 
this class doesn't need to know. See comments below

Very nice - done.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.cpp, line 665
bq.   https://reviews.apache.org/r/860/diff/2/?file=21214#file21214line665
bq.  
bq.   static local variables are not thread safe. Use a normal local 
variable constructing an intrusive pointer is trivial.

done.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 804
bq.   https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line804
bq.  
bq.   This doesn't need to be static, and you can avoid the casting. Just 
write
bq.   
bq.   void dequeueDone() { cmd-complete(); }
bq.   
bq.   and see further comment at the call site below

done.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 966
bq.   https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line966
bq.  
bq.   See comments above: this can now be
bq.   
bq.   
async-registerCallback(boost::bind(AsyncMessageAcceptCmd::dequeueDone, this))

done.


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 437
bq.   https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line437
bq.  
bq.   Store the DequeueCompletion pointer on the PersistableMessage, avoid 
this map lookup.

Sorry Alan, I'm being dense here - I don't understand.  Wouldn't the 
PersistableMessage still need a container for the DequeueCompletions, as there 
may be more than one dequeue pending for that message?  I'm thinking of fanout 
- same physical PersistableMessage shared among N queues.  There may be several 
different sessions dequeuing/accepting that message at the same time, right?  
How do we 'map' (heh) back from the P.M. to the sessions pending on the 
Message.Accept completion? 


bq.  On 2011-06-17 13:19:13, Alan Conway wrote:
bq.   /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.h, line 107
bq.   https://reviews.apache.org/r/860/diff/2/?file=21210#file21210line107
bq.  
bq.   Why the change from dequeue to list?

Big performance improvement with qpid-cpp-benchmark by moving from a dequeue to 
a list.  I'm guessing because we delete entries from the middle of the list(?)


- Kenneth


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/860/#review859
---


On 2011-06-16 15:25:17, Kenneth Giusti wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/860/
bq.  ---
bq.  
bq.  (Updated 2011-06-16 15:25:17)
bq.  
bq.  
bq.  Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Modifies the broker's handling 

[jira] [Commented] (QPID-3175) SSL support in Python client libraries

2011-06-20 Thread Rafael H. Schloming (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052167#comment-13052167
 ] 

Rafael H. Schloming commented on QPID-3175:
---

One comment on the patch. Is there a reason to change the arguments to the 
transport constructors? Would it be possible to have the keyfile, certfile, etc 
pulled out of the connection object that is passed to the transport rather than 
adding them as explicit arguments?

 SSL support in Python client libraries
 --

 Key: QPID-3175
 URL: https://issues.apache.org/jira/browse/QPID-3175
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: 0.8
 Environment: Windows XP, Python 2.7.1, (broker Red Hat MRG 1.3 on 
 RHEL 5.5)
Reporter: JAkub Scholz
Assignee: Rafael H. Schloming
 Fix For: 0.11

 Attachments: QPID-3175.patch


 I was trying to connect to my broker with SSL encrypted connection (both 
 PLAIN and EXTERNAL authentication methods). However, it seems to be not 
 working. I get following error messages:
 Traceback (most recent call last):
   File ssl-external.py, line 20, in module
 connection.open()
   File string, line 6, in open
   File 
 c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, 
 line 244, in open
 self.attach()
   File string, line 6, in attach
   File 
 c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, 
 line 262, in attach
 self._ewait(lambda: self._transport_connected and not self._unlinked())
   File 
 c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, 
 line 197, in _ewait
 self.check_error()
   File 
 c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, 
 line 190, in check_error
 raise self.error
 qpid.messaging.exceptions.ConnectError: [Errno 1] _ssl.c:499: 
 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
 In the source codes (messaging/transports.py), the SSL seems to be supported 
 and implemented, but it is not working. I didn't found any possibilities how 
 to pass the certificates to the SSL libraries and the wrap_socket call in 
 transports.py is calling the wrap_socket without any additional attributes 
 except the original socket.
 I didn't had the chance to test other platforms or Python versions, except 
 Python 2.4.3 on RHEL 5.5, where the SSL is not supported at all (the SSL 
 support in Python changed significantly with 2.6)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



[jira] [Commented] (QPID-3126) Make install fails with /usr/bin/ld: cannot find -lqmfengine error

2011-06-20 Thread Joel Bricker (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052168#comment-13052168
 ] 

Joel Bricker commented on QPID-3126:


If you swap the following two lines in cpp/src/qmf.mk:

  libqmf.la \
  libqmfengine.la   \

You can install normally from source, without have to run libtool yourself.  
This worked for me, at least.

 Make install fails with /usr/bin/ld: cannot find -lqmfengine error
 

 Key: QPID-3126
 URL: https://issues.apache.org/jira/browse/QPID-3126
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.8
 Environment: Linux  2.6.32-28-server #55-Ubuntu SMP Mon Jan 10 
 23:57:16 UTC 2011 x86_64 GNU/Linux
Reporter: Rafał Dowgird
  Labels: build
 Attachments: out.txt


 When 'make install' is run, the build fails with /usr/bin/ld: cannot find 
 -lqmfengine 
 It is possible to work around that by running libtool manually in /cpp/src, 
 with the list of libraries rearranged:
 ../libtool  --mode=install /usr/bin/install -c   libqpidtypes.la 
 libqpidcommon.la libqpidbroker.la libqpidclient.la libqmfengine.la 
 libqpidmessaging.la libqmf.la libqmf2.la libqmfconsole.la '/usr/local/lib'
 Note that libqmfengine.la was moved before libqpidmessaging.la, compared to 
 what make tries to run.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org



RE: Qpid python bindings for windows

2011-06-20 Thread Steve Huston
Hi Ovi,

The existing python bindings work on Windows.

-Steve

--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com


 -Original Message-
 From: Ovidiu Visan [mailto:ovi...@redhat.com] 
 Sent: Monday, June 20, 2011 12:33 PM
 To: dev@qpid.apache.org; us...@qpid.apache.org
 Subject: Qpid python bindings for windows
 
 
 Hi guys,
 
 We need to stand up a windows proxy, in the cloud backend, so 
 that the proxy can use local authentication to the booting 
 instance.  We want to control the proxy via qpid/qmf, to pass 
 commands down to it and get results back. For that we want to 
 use Python, so the question is: are there any qpid bindings 
 for python that would work in windows?
 
 Thank you.
 
 Ovi
 
 
 -
 Apache Qpid - AMQP Messaging Implementation
 Project:  http://qpid.apache.org
 Use/Interact: mailto:users-subscr...@qpid.apache.org
 
 


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org