Re: 0.18 inclusion request

[Rajith Attapattu]

I also struggled a bit with the name :)
I decided to use "qpid.session.is_hard_error" as it's self explanatory.

Rajith

On Tue, Jul 17, 2012 at 7:13 PM, Justin  wrote:
> Hi, Rajith.  I'm prepared to accept this, but I'm wondering whether
> "is_hard_error" is the right name for the system property.  Anyone have
> thoughts?
>
>
> On Mon, 16 Jul 2012, Rajith Attapattu wrote:
>
>> Hi Justin,
>>
>> Could please port the following two commits to the 0.18 release branch ?
>> They are associated with QPID-3575.
>> The latter (r1362161) has a system prop to revert to the old behaviour
>> if need be (as per Robbie's suggestion).
>>
>> http://svn.apache.org/viewvc?rev=1362162&view=rev
>> http://svn.apache.org/viewvc?rev=1362161&view=rev
>>
>> Regards,
>>
>> Rajith
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.18 inclusion request

[Justin]

Hi, Alex.  Since this is a feature addition (well, an extension) and not a 
bug fix, and since we've already produced the beta, I tend to think this 
one should wait for 0.20.


Justin

On Fri, 13 Jul 2012, Oleksandr Rudyy wrote:


Hi Justin,

Could you also consider inclusion of commit
http://svn.apache.org/viewvc?rev=1361239&view=rev
which adds the support for HTTPS protocol into Java Broker REST
interfaces and web management console?

Kind Regards,
Alex Rudyy

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4107) HA does not replicate alternate-exchange

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416707#comment-13416707
 ] 

Justin Ross commented on QPID-4107:
---

This is a defect, but one I'd characterize more as a functionality gap than an 
ordinary bug.  At any rate, I think it's too big a change leading up to RC1, so 
I think it should wait for the next release.

> HA does not replicate alternate-exchange
> 
>
> Key: QPID-4107
> URL: https://issues.apache.org/jira/browse/QPID-4107
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> In a HA cluster, the alternate-exchange setting on queues and exchanges is 
> not replicated.
> Note that to replicate it, you need to solve the problem of ensuring you have 
> replicated the required exchange before you try to set it on a newly 
> replicated queue (or exchange).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.18 inclusion request

[Justin]

Hi, Rajith.  I'm prepared to accept this, but I'm wondering whether 
"is_hard_error" is the right name for the system property.  Anyone have 
thoughts?


On Mon, 16 Jul 2012, Rajith Attapattu wrote:


Hi Justin,

Could please port the following two commits to the 0.18 release branch ?
They are associated with QPID-3575.
The latter (r1362161) has a system prop to revert to the old behaviour
if need be (as per Robbie's suggestion).

http://svn.apache.org/viewvc?rev=1362162&view=rev
http://svn.apache.org/viewvc?rev=1362161&view=rev

Regards,

Rajith

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4131) Broker should close connection on transaction timeout rather than close session for better compatibility with Java clients

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416699#comment-13416699
 ] 

Justin Ross commented on QPID-4131:
---

Reviewed by Philip.  Approved for 0.18.

> Broker should close connection on transaction timeout rather than close 
> session for better compatibility with Java clients
> --
>
> Key: QPID-4131
> URL: https://issues.apache.org/jira/browse/QPID-4131
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.14, 0.16, 0.18
>Reporter: Keith Wall
>Assignee: Philip Harvey
> Fix For: 0.19
>
>
> Older versions of the Java Broker (0.5) used to close the connection in the 
> event of transaction time (on detection of open or idle transaction) rather 
> than close the session.  When the transaction timeout feature was forward 
> ported to 0.11, the decision was made to close the session for both 0-10 and 
> 0-8...0-9-1.  Unfortunately the Java client does not handle the session close 
> correctly and this results in a connection leak.
> This change will revert the 0-8...0-9-1 code paths within the Java Broker to 
> use connection close rather than session close.  This will ensure that the 
> Java Broker remains compatibility with Java Clients that suffer this problem..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4121) ConcurrentModificationException reported by HouseKeepingTask while closing session

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416695#comment-13416695
 ] 

Justin Ross commented on QPID-4121:
---

Reviewed by Keith.  Approved for 0.18.

> ConcurrentModificationException reported by HouseKeepingTask while closing 
> session
> --
>
> Key: QPID-4121
> URL: https://issues.apache.org/jira/browse/QPID-4121
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.16, 0.17, 0.18
>Reporter: Philip Harvey
>Assignee: Keith Wall
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4121-AMQProtocolEngine-now-uses-lock-to-prevent.patch
>
>
> A ConcurrentModificationException was reported by a housekeeping thread while 
> closing a session. It was closing the session because its transaction was 
> open or idle for longer than the configured maximum time.
> Here is the log excerpt:
> {noformat}
> 2012-07-02 19:25:12,210 WARN [notifier:VirtualHostHouseKeepingTask] 
> server.AMQChannel (AMQChannel.java:1519) - IDLE TRANSACTION ALERT 
> org.apache.qpid.server
> .logging.subjects.ChannelLogSubject@4ca3b645 503084 ms
> 2012-07-02 23:48:41,979 WARN [notifier:VirtualHostHouseKeepingTask] 
> server.AMQChannel (AMQChannel.java:1519) - IDLE TRANSACTION ALERT 
> org.apache.qpid.server
> .logging.subjects.ChannelLogSubject@3b1d0a16 584211 ms
> 2012-07-02 23:48:42,033 ERROR [notifier:VirtualHostHouseKeepingTask] 
> virtualhost.VirtualHostImpl$VirtualHostHouseKeepingTask 
> (VirtualHostImpl.java:407) - Exception in housekeeping for connection: 
> /xxx.xxx.xxx.xx:50639(x)
>   java.util.ConcurrentModificationException
>   at 
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
>   at java.util.AbstractList$Itr.next(AbstractList.java:343)
>   at 
> org.apache.qpid.server.txn.LocalTransaction.rollback(LocalTransaction.java:297)
>   at org.apache.qpid.server.AMQChannel.close(AMQChannel.java:535)
>   at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.closeChannel(AMQProtocolEngine.java:727)
>   at 
> org.apache.qpid.server.protocol.AMQProtocolEngine.closeSession(AMQProtocolEngine.java:1350)
>   at 
> org.apache.qpid.server.AMQChannel.checkTransactionStatus(AMQChannel.java:1530)
>   at 
> org.apache.qpid.server.virtualhost.VirtualHostImpl$VirtualHostHouseKeepingTask.execute(VirtualHostImpl.java:400)
>   at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:61)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>   at 
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101
>   (ScheduledThreadPoolExecutor.java:98)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic
>  (ScheduledThreadPoolExecutor.java:180)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4145) HA Minor fixes to recovery

[Alan Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416619#comment-13416619
 ] 

Alan Conway commented on QPID-4145:
---

Fix on trunk, request merge to 0.18

 
r1362658 | aconway | 2012-07-17 17:23:12 -0400 (Tue, 17 Jul 2012) | 7 lines

QPID-4145: HA Minor fixes to recovery

- Demote timed-out backups from ready to catch-up.
- Don't cancel connected backups on timeout, only disconnected ones.
- Don't allow promotion of a catch-up broker.
- Minor logging improvement.


> HA Minor fixes to recovery
> --
>
> Key: QPID-4145
> URL: https://issues.apache.org/jira/browse/QPID-4145
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18
>
>
> - Demote timed-out backups from ready to catch-up.
> - Don't cancel connected backups on timeout, only disconnected ones.
> - Don't allow promotion of a catch-up broker.
> - Minor logging improvement.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-4136) HA sporadic failures in ha_tests

[Alan Conway (JIRA)]

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

Alan Conway resolved QPID-4136.
---

Resolution: Fixed

Merged to 0.18 r1362654

> HA sporadic failures in ha_tests
> 
>
> Key: QPID-4136
> URL: https://issues.apache.org/jira/browse/QPID-4136
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.7
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18
>
>
> ha_tests.py fails sporadically. 2 different types of failure have been 
> observed:
>  failure 1
> ha_tests.RecoveryTests.test_queue_hold 
>  fail
> Error during test:  Traceback (most recent call last):
> File "/home/aconway/qpid/dbg/src/tests/python/commands/qpid-python-test", 
> line 340, in run
>   phase()
> File "/home/aconway/qpid/qpid/cpp/src/tests/ha_tests.py", line 901, in 
> test_queue_hold
>   cluster[1].assert_browse_backup("q1", [str(i) for i in 
> range(100)+range(100,200)])
> File "/home/aconway/qpid/qpid/cpp/src/tests/ha_tests.py", line 158, in 
> assert_browse_backup
>   assert_browse_retry(bs, queue, expected, **kwargs)
> File "/home/aconway/qpid/qpid/cpp/src/tests/brokertest.py", line 466, in 
> assert_browse_retry
>   assert expect_contents == actual_contents, msg
>   AssertionError: browse failed: ['0', '1', '2', '3', '4', '5', '6', '7', 
> '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', 
> '21', '22', '23', '24', '25', '26', '27', '28', '29', '30', '31', '32', '33', 
> '34', '35', '36', '37', '38', '39', '40', '41', '42', '43', '44', '45', '46', 
> '47', '48', '49', '50', '51', '52', '53', '54', '55', '56', '57', '58', '59', 
> '60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '70', '71', '72', 
> '73', '74', '75', '76', '77', '78', '79', '80', '81', '82', '83', '84', '85', 
> '86', '87', '88', '89', '90', '91', '92', '93', '94', '95', '96', '97', '98', 
> '99', '100', '101', '102', '103', '104', '105', '106', '107', '108', '109', 
> '110', '111', '112', '113', '114', '115', '116', '117', '118', '119', '120', 
> '121', '122', '123', '124', '125', '126', '127', '128', '129', '130', '131', 
> '132', '133', '134', '135', '136', '137', '138', '139', '140', '141', '142', 
> '143', '144', '145', '146', '147', '148', '149', '150', '151', '152', '153', 
> '154', '155', '156', '157', '158', '159', '160', '161', '162', '163', '164', 
> '165', '166', '167', '168', '169', '170', '171', '172', '173', '174', '175', 
> '176', '177', '178', '179', '180', '181', '182', '183', '184', '185', '186', 
> '187', '188', '189', '190', '191', '192', '193', '194', '195', '196', '197', 
> '198', '199'] != []
> - failure 2
> ha_tests.RecoveryTests.test_queue_hold .. fail
> Error during test:  Traceback (most recent call last):
> File 
> "/var/lib/jenkins/workspace/Qpid-cpp/qpid/cpp/src/tests/python/commands/qpid-python-test",
>  line 340, in run
>   phase()
> File 
> "/var/lib/jenkins/workspace/Qpid-cpp/qpid/cpp/src/tests/ha_tests.py", line 
> 891, in test_queue_hold
>   assertSyncTimeout(s1)
> File 
> "/var/lib/jenkins/workspace/Qpid-cpp/qpid/cpp/src/tests/ha_tests.py", line 
> 875, in assertSyncTimeout
>   self.fail("Expected Timeout exception")
> File "/usr/lib64/python2.6/unittest.py", line 316, in fail
>   raise self.failureException, msg
>   AssertionError: Expected Timeout exception
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-4133) Non-responsive peer in federated link can result in entire cluster shutdown

[Alan Conway (JIRA)]

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

Alan Conway resolved QPID-4133.
---

Resolution: Fixed

Merged to 0.18 r1362653

> Non-responsive peer in federated link can result in entire cluster shutdown
> ---
>
> Key: QPID-4133
> URL: https://issues.apache.org/jira/browse/QPID-4133
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.12
>Reporter: Jason Dillaman
>Assignee: Alan Conway
> Attachments: jira-4133.patch
>
>
> If a federated link is established to a source broker that is slow to respond 
> with the AMQP handshake, the destination broker cluster will shutdown with an 
> "Unknown connection" error.  
> Exception constructed: Unknown connection: Frame[BEbe; channel=0; 
> {ClusterConnectionDeliverDoOutputBody: limit=2048; }] control 
> 2.0.0.0:22138-14 (qpid/cluster/Cluster.cpp:542)
> Steps to Reproduce:
> 1. Configure a clustered broker
> 2. Start netcat in listen mode (nc -l 6000)
> 3. Add a route between the clustered broker and nc (qpid-route queue add 
> localhost:5672 localhost:6000 amq.fanout foo)
> 4. Clustered broker shuts down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-4145) HA Minor fixes to recovery

[Alan Conway (JIRA)]

Alan Conway created QPID-4145:
-

 Summary: HA Minor fixes to recovery
 Key: QPID-4145
 URL: https://issues.apache.org/jira/browse/QPID-4145
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.17
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.18


- Demote timed-out backups from ready to catch-up.
- Don't cancel connected backups on timeout, only disconnected ones.
- Don't allow promotion of a catch-up broker.
- Minor logging improvement.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4136) HA sporadic failures in ha_tests

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416549#comment-13416549
 ] 

Justin Ross commented on QPID-4136:
---

Trivial change, approved for 0.18.

> HA sporadic failures in ha_tests
> 
>
> Key: QPID-4136
> URL: https://issues.apache.org/jira/browse/QPID-4136
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.7
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18
>
>
> ha_tests.py fails sporadically. 2 different types of failure have been 
> observed:
>  failure 1
> ha_tests.RecoveryTests.test_queue_hold 
>  fail
> Error during test:  Traceback (most recent call last):
> File "/home/aconway/qpid/dbg/src/tests/python/commands/qpid-python-test", 
> line 340, in run
>   phase()
> File "/home/aconway/qpid/qpid/cpp/src/tests/ha_tests.py", line 901, in 
> test_queue_hold
>   cluster[1].assert_browse_backup("q1", [str(i) for i in 
> range(100)+range(100,200)])
> File "/home/aconway/qpid/qpid/cpp/src/tests/ha_tests.py", line 158, in 
> assert_browse_backup
>   assert_browse_retry(bs, queue, expected, **kwargs)
> File "/home/aconway/qpid/qpid/cpp/src/tests/brokertest.py", line 466, in 
> assert_browse_retry
>   assert expect_contents == actual_contents, msg
>   AssertionError: browse failed: ['0', '1', '2', '3', '4', '5', '6', '7', 
> '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', 
> '21', '22', '23', '24', '25', '26', '27', '28', '29', '30', '31', '32', '33', 
> '34', '35', '36', '37', '38', '39', '40', '41', '42', '43', '44', '45', '46', 
> '47', '48', '49', '50', '51', '52', '53', '54', '55', '56', '57', '58', '59', 
> '60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '70', '71', '72', 
> '73', '74', '75', '76', '77', '78', '79', '80', '81', '82', '83', '84', '85', 
> '86', '87', '88', '89', '90', '91', '92', '93', '94', '95', '96', '97', '98', 
> '99', '100', '101', '102', '103', '104', '105', '106', '107', '108', '109', 
> '110', '111', '112', '113', '114', '115', '116', '117', '118', '119', '120', 
> '121', '122', '123', '124', '125', '126', '127', '128', '129', '130', '131', 
> '132', '133', '134', '135', '136', '137', '138', '139', '140', '141', '142', 
> '143', '144', '145', '146', '147', '148', '149', '150', '151', '152', '153', 
> '154', '155', '156', '157', '158', '159', '160', '161', '162', '163', '164', 
> '165', '166', '167', '168', '169', '170', '171', '172', '173', '174', '175', 
> '176', '177', '178', '179', '180', '181', '182', '183', '184', '185', '186', 
> '187', '188', '189', '190', '191', '192', '193', '194', '195', '196', '197', 
> '198', '199'] != []
> - failure 2
> ha_tests.RecoveryTests.test_queue_hold .. fail
> Error during test:  Traceback (most recent call last):
> File 
> "/var/lib/jenkins/workspace/Qpid-cpp/qpid/cpp/src/tests/python/commands/qpid-python-test",
>  line 340, in run
>   phase()
> File 
> "/var/lib/jenkins/workspace/Qpid-cpp/qpid/cpp/src/tests/ha_tests.py", line 
> 891, in test_queue_hold
>   assertSyncTimeout(s1)
> File 
> "/var/lib/jenkins/workspace/Qpid-cpp/qpid/cpp/src/tests/ha_tests.py", line 
> 875, in assertSyncTimeout
>   self.fail("Expected Timeout exception")
> File "/usr/lib64/python2.6/unittest.py", line 316, in fail
>   raise self.failureException, msg
>   AssertionError: Expected Timeout exception
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4133) Non-responsive peer in federated link can result in entire cluster shutdown

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416538#comment-13416538
 ] 

Justin Ross commented on QPID-4133:
---

Reviewed by Alan and Gordon.  Approved for 0.18.

> Non-responsive peer in federated link can result in entire cluster shutdown
> ---
>
> Key: QPID-4133
> URL: https://issues.apache.org/jira/browse/QPID-4133
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.12
>Reporter: Jason Dillaman
>Assignee: Alan Conway
> Attachments: jira-4133.patch
>
>
> If a federated link is established to a source broker that is slow to respond 
> with the AMQP handshake, the destination broker cluster will shutdown with an 
> "Unknown connection" error.  
> Exception constructed: Unknown connection: Frame[BEbe; channel=0; 
> {ClusterConnectionDeliverDoOutputBody: limit=2048; }] control 
> 2.0.0.0:22138-14 (qpid/cluster/Cluster.cpp:542)
> Steps to Reproduce:
> 1. Configure a clustered broker
> 2. Start netcat in listen mode (nc -l 6000)
> 3. Add a route between the clustered broker and nc (qpid-route queue add 
> localhost:5672 localhost:6000 amq.fanout foo)
> 4. Clustered broker shuts down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request: qpidd refactor

[Gordon Sim]

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

(Updated July 17, 2012, 7:46 p.m.)


Review request for qpid, Alan Conway and Kenneth Giusti.


Changes
---

Changes based on Alans feedback (didn't yet make any attempt to expand use of 
boost as suggested).


Description
---

== Background ==

I've been looking at what would be required to get AMQP 1.0 support in
the qpidd broker (using proton-c). In that context I felt there was a
need to refactor the broker code, particularly that part that would be
shared between different protocol versions. Part of the motivation was
clearer separation of 0-10 specific logic, so that 1.0 logic could be
introduced as an alternative. However part of it was also simply the
recognition of some long-standing problems that we have never stopped
to address.

So, here is a patch representing my ideas on what is needed. This is
already a little stale (patch was generated against r1331342) and
needs a rebase. However I think the basic ideas involved are clear
enough that it would be worth getting some early feedback.

== Key Changes ==

qpid::broker::Message

This is now supposed to be a protocol neutral representation of a
message. It no longer exposes qpid::framing::FrameSet. It can be based
on data received in different encodings (this patch only includes the
existing 0-10 encoding).

The immutable, sharable state is separated from the mutable
queue-specific state. Messages themselves are no longer held through a
shared pointer but are passed by reference or copied if needed. The
immutable state (essentially the data as received) *is* still shared
and referenced internally through an intrusive pointer. There is no
longer a message level lock. A message instance is 'owned' by
someother entity (usually the queue it is on) which controls
concurrent access/modification if necessary.

The persistence context is a separate part of the message
also. Currently that can be shared between two message instances if
desired.

qpid::broker::Messages

Switched from using qpid::broker::QueuedMessage (which relied on
shared pointer to message itself and made sequence number the explicit
- and only - way to refer to a specific message) to using modified
Message class directly and a new qpid::broker::QueueCursor.

The cursor is opaque outside the Messages implementation to which it
relates. It provides a way to refer to a specific message (without
directly using sequence number, though at present that is what is used
'under the covers') and/or to track progress through a sequence of
messages (for consumers or other iterating entities).

I.e. its an iterator to a Message within its containing Messages
instance that is not invalidated by changes to that container.

A Messages instance *owns* the Message instances within it. Other
classes access this through a reference or (raw) pointer, or if needed
copy it (the immutable part can be - and is - safely shared).

The codepath for browse/consume is a lot more unified now. You use a
cursor and call Messages::next() in each case. This also lays the
foundation for selectors.

The simplified Messages interface led to a simplied
MessageDistributor. There is still a little more to do to clarify
these separate roles (or indeed perhaps unify them?) but more on that
later.

qpid::broker::amqp_0_10::MessageTransfer

This represents the familiar 0-10 encoding of a message. This class is
broadly similar to the old Message class, based on a FrameSet. However
it represents the shared and essentially immutable state. The
sendHeader() method now explicitly takes a copy of the original
headers and adds to it or otherwise modifies it if needed (e.g. for
redelivered flag, ttl, annotations etc).

[Ideally I'd like to move more of the 0-10 specific classes out of
qpid::broker and into qpid::broker::amqp_0_10, but that has no
functional relevance so I've left existing classes alone for now.]

qpid::broker::Consumer

The deliver() method now takes a QueueCursor (representing a 'handle'
to this message for use in subsequent operations such as accept,
relese etc) and a *constant reference* to the Message itself
(i.e. consumers can't alter the state of the message on the queue
directly, but only through operations on the queue itself).

qpid::broker::QueueRegistry

The actual queue creation has been pulled out into a base class,
QueueFactory. The actual class of the Queue returned can now be varied
and there are two subclasses in the current patch. The first is a
replacement for the ring policy logic, whereby messages are removed
from the queue in order to keep the queue from growing above a
configured limit. The second is for last value queues and simply pulls
the special case behaviour out of the common code path.

The handling of queue configuration has also been made cleaner and
more uniform, based

[jira] [Commented] (QPID-4036) Failed client connections permanently exhaust broker's max connections limit

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416523#comment-13416523
 ] 

Justin Ross commented on QPID-4036:
---

Reviewed by Alan.  Approved for 0.18.  Corresponding commit is 
http://svn.apache.org/viewvc?view=revision&revision=1360214 .

> Failed client connections permanently exhaust broker's max connections limit
> 
>
> Key: QPID-4036
> URL: https://issues.apache.org/jira/browse/QPID-4036
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.16
> Environment: CentOS release 5.5 (Final)
> Linux 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 
> x86_64 GNU/Linux
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>Reporter: Paul Colby
>Priority: Critical
>  Labels: sasl, ssl
>
> I'm running a set of Qpid 0.16 C++ brokers with configuration like:
> {code}
> cluster-name="mm-queue-cluster"
> cluster-cman=yes
> cluster-mechanism=PLAIN
> cluster-username=broker
> cluster-password=abc123
> cluster-url=ssl:gateway02:5671
> auth=yes
> ssl-cert-db=/etc/qpid/certs/broker
> ssl-cert-password-file=/etc/qpid/certs/pass.txt
> ssl-cert-name=broker.messagemedia.com.au
> require-encryption=yes
> {code}
> ie the broker is requiring both encryption and authentication (configured 
> SASL mech list is CRAM-MD5 DIGEST-MD5 EXTERNAL PLAIN).
> Now, if a client (let's use {{qpid-stat}} for example) connects via SSL 
> (amqps) and authenticates successfully, then everything is happy.
> However, if a client repeatedly fails to use SSL and/or fails to provide 
> credentials, then the broker loses one of it's configured max connections 
> every time!
> So, for example, if we start the broker using the configuration shown above, 
> then do this:
> {code}for i in `seq 1 550`; do echo $i; qpid-stat -q ; done{code}
> The above loop will report ~ 500 {{AuthenticationFailure}} errors, then 
> switch to {{ConnectionError}} errors.  Once the {{ConnectionError}} errors 
> begin, all further connections to the broker will be rejected - permanently 
> (until the broker is restarted), with the broker logging:
> {code}error Client max connection count limit exceeded: 500 connection 
> refused{code}
> From my testing, the following loops never cause an issue (with this 
> configuration):
> {code:none}
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://guest/guest@localhost 
> -q ; done # Works as expected.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://guest/wrong@localhost 
> -q ; done # AuthenticationFailure as expected.
> {code}
> Whereas any of the following will break the broker:
> {code:none}
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://guest/guest@localhost 
> -q ; done # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://guest/wrong@localhost 
> -q ; done # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://localhost -q ; done 
> # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://localhost -q ; done
> # AuthenticationFailure, then ConnectionError.
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4144) HA broker deadlocks on broeker::QueueRegistry lock and ha::Primary lock

[Alan Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416393#comment-13416393
 ] 

Alan Conway commented on QPID-4144:
---

Fixed on trunk, request merge to 0.18 branch.


r1362584 | aconway | 2012-07-17 13:39:54 -0400 (Tue, 17 Jul 2012) | 10 lines

QPID-4144 HA broker deadlocks on broker::QueueRegistry lock and ha::Primary lock

Running tests repeatedly, the broker deadlocked with the attached stack trace.

The problem call sequences are:
1. QueueRegistry::destroy takes QueuerRegistry lock > 
ConfigurationObserver::queueDestroy > ha::Primary::queueDestroy takes Primary 
lock.
2. ConnectionObserver::opened cals Primary::opened lock> 
RemoteBackup>getQueues().eachQueue

This patch breaks the deadlock at both ends: QueueRegistry no longer holds the 
lock across the observer call and Primary does not hold the lock across 
eachQueue.



> HA broker deadlocks on broeker::QueueRegistry lock and ha::Primary lock
> ---
>
> Key: QPID-4144
> URL: https://issues.apache.org/jira/browse/QPID-4144
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18
>
> Attachments: thread-dump.txt
>
>
> Running tests repeatedly, the broker deadlocked with the attached stack trace.
> The problem call sequences are:
> 1. QueueRegistry::destroy takes QueuerRegistry lock > 
> ConfigurationObserver::queueDestroy > ha::Primary::queueDestroy takes Primary 
> lock.
> 2. ConnectionObserver::opened cals Primary::opened lock> 
> RemoteBackup>getQueues().eachQueue
> This patch breaks the deadlock at both ends: QueueRegistry no longer holds 
> the lock across the observer call and Primary does not hold the lock across 
> eachQueue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4144) HA broker deadlocks on broeker::QueueRegistry lock and ha::Primary lock

[Alan Conway (JIRA)]

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

Alan Conway updated QPID-4144:
--

Attachment: thread-dump.txt

Thread dump of the deadlocked process.

> HA broker deadlocks on broeker::QueueRegistry lock and ha::Primary lock
> ---
>
> Key: QPID-4144
> URL: https://issues.apache.org/jira/browse/QPID-4144
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18
>
> Attachments: thread-dump.txt
>
>
> Running tests repeatedly, the broker deadlocked with the attached stack trace.
> The problem call sequences are:
> 1. QueueRegistry::destroy takes QueuerRegistry lock > 
> ConfigurationObserver::queueDestroy > ha::Primary::queueDestroy takes Primary 
> lock.
> 2. ConnectionObserver::opened cals Primary::opened lock> 
> RemoteBackup>getQueues().eachQueue
> This patch breaks the deadlock at both ends: QueueRegistry no longer holds 
> the lock across the observer call and Primary does not hold the lock across 
> eachQueue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-4144) HA broker deadlocks on broeker::QueueRegistry lock and ha::Primary lock

[Alan Conway (JIRA)]

Alan Conway created QPID-4144:
-

 Summary: HA broker deadlocks on broeker::QueueRegistry lock and 
ha::Primary lock
 Key: QPID-4144
 URL: https://issues.apache.org/jira/browse/QPID-4144
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.17
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.18
 Attachments: thread-dump.txt

Running tests repeatedly, the broker deadlocked with the attached stack trace.

The problem call sequences are:
1. QueueRegistry::destroy takes QueuerRegistry lock > 
ConfigurationObserver::queueDestroy > ha::Primary::queueDestroy takes Primary 
lock.
2. ConnectionObserver::opened cals Primary::opened lock> 
RemoteBackup>getQueues().eachQueue

This patch breaks the deadlock at both ends: QueueRegistry no longer holds the 
lock across the observer call and Primary does not hold the lock across 
eachQueue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request: qpidd refactor

[Gordon Sim]

> On July 17, 2012, 3:01 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/broker/QueueCursor.cpp, line 35
> > 
> >
> > const Message&?

Agreed.


> On July 17, 2012, 3:01 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/broker/QueueCursor.cpp, line 41
> > 
> >
> > Could say just "return m.getState() ==..."

Agreed.


> On July 17, 2012, 3:01 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp, line 74
> > 
> >
> > Oops! Code inside an assert()! Will explode on in release build.

Oops indeed! Will fix that right away.


> On July 17, 2012, 3:01 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp, line 136
> > 
> >
> > Not important but: why pass SequenceNumber by reference? It's just an 
> > int32_t

Agreed.


> On July 17, 2012, 3:01 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp, line 57
> > 
> >
> > Maybe move this down closer to its use, its a bit puzzling when seen 
> > alone.

Sure.


> On July 17, 2012, 3:01 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp, line 130
> > 
> >
> > There  is still a bug here (not introduced by you though.) Seek from 0 
> > won't get the front of the queue if the sequence numbers have wrapped. Want 
> > to make sure we leave a comment or note of that somewhere.

I think that bug is fixed, as we now no longer do any sequence number 
comparison if we simply want the front message. I.e. this method no longer just 
calls getNext() with position 0. (The 0 in the last parameter is a pointer to a 
SequenceNumber, so 0 means null not actual 0 value).

Thanks for all the excellent feedback!


- Gordon


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


On July 17, 2012, 12:38 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5833/
> ---
> 
> (Updated July 17, 2012, 12:38 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Kenneth Giusti.
> 
> 
> Description
> ---
> 
> == Background ==
> 
> I've been looking at what would be required to get AMQP 1.0 support in
> the qpidd broker (using proton-c). In that context I felt there was a
> need to refactor the broker code, particularly that part that would be
> shared between different protocol versions. Part of the motivation was
> clearer separation of 0-10 specific logic, so that 1.0 logic could be
> introduced as an alternative. However part of it was also simply the
> recognition of some long-standing problems that we have never stopped
> to address.
> 
> So, here is a patch representing my ideas on what is needed. This is
> already a little stale (patch was generated against r1331342) and
> needs a rebase. However I think the basic ideas involved are clear
> enough that it would be worth getting some early feedback.
> 
> == Key Changes ==
> 
> qpid::broker::Message
> 
> This is now supposed to be a protocol neutral representation of a
> message. It no longer exposes qpid::framing::FrameSet. It can be based
> on data received in different encodings (this patch only includes the
> existing 0-10 encoding).
> 
> The immutable, sharable state is separated from the mutable
> queue-specific state. Messages themselves are no longer held through a
> shared pointer but are passed by reference or copied if needed. The
> immutable state (essentially the data as received) *is* still shared
> and referenced internally through an intrusive pointer. There is no
> longer a message level lock. A message instance is 'owned' by
> someother entity (usually the queue it is on) which controls
> concurrent access/modification if necessary.
> 
> The persistence context is a separate part of the message
> also. Currently that can be shared between two message instances if
> desired.
> 
> qpid::broker::Messages
> 
> Switched from using qpid::broker::QueuedMessage (which relied on
> shared pointer to message itself and made sequence number the explicit
> - and only - way to refer to a specific message) to using modified
> Message class directly and a new qpid::broker::QueueCursor.
> 
> The cursor is opaque outside the Messages implementation to which it
> relates. It provides a way to refer to a specific message (without

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Attachment: 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch

attached the correct patch

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch, 
> 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Attachment: (was: 
0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch)

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch, 
> 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4103:
---

Assignee: Keith Wall  (was: Philip Harvey)

please review

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch, 
> 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Reopened] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey reopened QPID-4103:
-

  Assignee: Philip Harvey  (was: Keith Wall)

tests failing  on Jenkins instance that contains spaces in directory names

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch, 
> 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Status: Ready To Review  (was: In Progress)

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch, 
> 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Attachment: 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch

attached patch

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch, 
> 0001-QPID-4103-now-getting-test-file-paths-as-URIs-instea.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request: qpidd refactor

[Alan Conway]

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


Looked at the HA stuff - looks good, improved in several places e.g. avoiding 
queue scans now you're using a map rather than a SequenceSet and using seek.  
One serious issue - code in an assert, the remaining comments you can take or 
leave, non of them is important.


/trunk/qpid/cpp/src/qpid/broker/QueueCursor.cpp


const Message&?



/trunk/qpid/cpp/src/qpid/broker/QueueCursor.cpp


Could say just "return m.getState() ==..."



/trunk/qpid/cpp/src/qpid/broker/QueueDepth.h


Could be simplified with boost::operators. You only have to define ==, <, 
+=, -= and the template generates the rest.



/trunk/qpid/cpp/src/qpid/broker/QueueDepth.h


Could use boost::optional



/trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp


Oops! Code inside an assert()! Will explode on in release build.



/trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp


Not important but: why pass SequenceNumber by reference? It's just an 
int32_t



/trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp


Maybe move this down closer to its use, its a bit puzzling when seen alone.



/trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp


There  is still a bug here (not introduced by you though.) Seek from 0 
won't get the front of the queue if the sequence numbers have wrapped. Want to 
make sure we leave a comment or note of that somewhere.


- Alan Conway


On July 17, 2012, 12:38 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5833/
> ---
> 
> (Updated July 17, 2012, 12:38 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Kenneth Giusti.
> 
> 
> Description
> ---
> 
> == Background ==
> 
> I've been looking at what would be required to get AMQP 1.0 support in
> the qpidd broker (using proton-c). In that context I felt there was a
> need to refactor the broker code, particularly that part that would be
> shared between different protocol versions. Part of the motivation was
> clearer separation of 0-10 specific logic, so that 1.0 logic could be
> introduced as an alternative. However part of it was also simply the
> recognition of some long-standing problems that we have never stopped
> to address.
> 
> So, here is a patch representing my ideas on what is needed. This is
> already a little stale (patch was generated against r1331342) and
> needs a rebase. However I think the basic ideas involved are clear
> enough that it would be worth getting some early feedback.
> 
> == Key Changes ==
> 
> qpid::broker::Message
> 
> This is now supposed to be a protocol neutral representation of a
> message. It no longer exposes qpid::framing::FrameSet. It can be based
> on data received in different encodings (this patch only includes the
> existing 0-10 encoding).
> 
> The immutable, sharable state is separated from the mutable
> queue-specific state. Messages themselves are no longer held through a
> shared pointer but are passed by reference or copied if needed. The
> immutable state (essentially the data as received) *is* still shared
> and referenced internally through an intrusive pointer. There is no
> longer a message level lock. A message instance is 'owned' by
> someother entity (usually the queue it is on) which controls
> concurrent access/modification if necessary.
> 
> The persistence context is a separate part of the message
> also. Currently that can be shared between two message instances if
> desired.
> 
> qpid::broker::Messages
> 
> Switched from using qpid::broker::QueuedMessage (which relied on
> shared pointer to message itself and made sequence number the explicit
> - and only - way to refer to a specific message) to using modified
> Message class directly and a new qpid::broker::QueueCursor.
> 
> The cursor is opaque outside the Messages implementation to which it
> relates. It provides a way to refer to a specific message (without
> directly using sequence number, though at present that is what is used
> 'under the covers') and/or to track progress through a sequence of
> messages (for consumers or other iterating entities).
> 
> I.e. its an iterator to a Message within its containing Messages
> instance that is not invalidated by changes to that container.
> 
> A Messages instance *owns* the Me

[jira] [Resolved] (QPID-4129) C++ Broker failed client authentication in multi-node cluster causes connection leak

[Chuck Rolke (JIRA)]

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

Chuck Rolke resolved QPID-4129.
---

   Resolution: Fixed
Fix Version/s: Future

This appears to be a duplicate of QPID-4036

> C++ Broker failed client authentication in multi-node cluster causes 
> connection leak
> 
>
> Key: QPID-4129
> URL: https://issues.apache.org/jira/browse/QPID-4129
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.16
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: Future
>
>
> When an HA cluster has at least one connected peer cluster member and a 
> client connection fails authentication then the broker::Connection is leaked.
> The issue does not affect standalone brokers nor does it affect a clustered 
> broker with no connected peers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4129) C++ Broker failed client authentication in multi-node cluster causes connection leak

[Chuck Rolke (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416252#comment-13416252
 ] 

Chuck Rolke commented on QPID-4129:
---

Fixed in r1360214
http://qpid.2158936.n2.nabble.com/svn-commit-r1360214-qpid-trunk-qpid-cpp-src-qpid-cluster-Connection-cpp-td7579508.html


> C++ Broker failed client authentication in multi-node cluster causes 
> connection leak
> 
>
> Key: QPID-4129
> URL: https://issues.apache.org/jira/browse/QPID-4129
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.16
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> When an HA cluster has at least one connected peer cluster member and a 
> client connection fails authentication then the broker::Connection is leaked.
> The issue does not affect standalone brokers nor does it affect a clustered 
> broker with no connected peers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4143) Various tweaks to Java perftest configuration

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-4143:
-

Fix Version/s: (was: Future)
   0.19

> Various tweaks to Java perftest configuration
> -
>
> Key: QPID-4143
> URL: https://issues.apache.org/jira/browse/QPID-4143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Philip Harvey
>Assignee: Keith Wall
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4143-tweaked-topic-test-config-to-introduce-a-s.patch
>
>
> The java/perftests/ module is functional, but some of the test JSON/JS files 
> need to be tweaked, and some error reporting should be improved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-4103:
-

Fix Version/s: (was: 0.17)
   0.19

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-4143) Various tweaks to Java perftest configuration

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416232#comment-13416232
 ] 

Keith Wall commented on QPID-4143:
--

Patch applied.

> Various tweaks to Java perftest configuration
> -
>
> Key: QPID-4143
> URL: https://issues.apache.org/jira/browse/QPID-4143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Philip Harvey
>Assignee: Keith Wall
>Priority: Minor
> Fix For: 0.19
>
> Attachments: 
> 0001-QPID-4143-tweaked-topic-test-config-to-introduce-a-s.patch
>
>
> The java/perftests/ module is functional, but some of the test JSON/JS files 
> need to be tweaked, and some error reporting should be improved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-4103.
--

Resolution: Fixed

Patch applied.

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Attachment: 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch

attached patch

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Attachment: (was: 
0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch)

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request: qpidd refactor

[Alan Conway]

On Tue, 2012-07-17 at 12:38 +, Gordon Sim wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5833/
> ---
> 
> (Updated July 17, 2012, 12:38 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Kenneth Giusti.
> 
> 
> Changes
> ---
> 
> Rebased (to r1362014). Removed irrelevant changes (to cluster and to Codec 
> interface). Fixed xml exchange.
> 
> Current status: there is one intermittent failure in the ha tests 
> (ha_tests.LongTests.test_failover_send_receive); some unit tests still 
> disabled; all other tests are passing reliably.

That test is failing intermittently on trunk/0.18 also so that may not
be related to your changes.


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-4143) Various tweaks to Java perftest configuration

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4143:
---

Assignee: Keith Wall  (was: Philip Harvey)

please review and commit if you're happy. Please don't close the JIRA yet - 
there may be a couple more changes coming.

> Various tweaks to Java perftest configuration
> -
>
> Key: QPID-4143
> URL: https://issues.apache.org/jira/browse/QPID-4143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Philip Harvey
>Assignee: Keith Wall
>Priority: Minor
> Fix For: Future
>
> Attachments: 
> 0001-QPID-4143-tweaked-topic-test-config-to-introduce-a-s.patch
>
>
> The java/perftests/ module is functional, but some of the test JSON/JS files 
> need to be tweaked, and some error reporting should be improved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey reassigned QPID-4103:
---

Assignee: Keith Wall  (was: Philip Harvey)

please review and commit if you're happy

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Attachment: 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch

attached patch for failing test on jdk1.7

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4103:


Status: Ready To Review  (was: In Progress)

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-modified-test-so-th.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Reopened] (QPID-4103) [Java Performance Tests] Allow specifying of test configuration with Javascript

[Philip Harvey (JIRA)]

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

Philip Harvey reopened QPID-4103:
-

  Assignee: Philip Harvey  (was: Keith Wall)

JavaScriptEvaluatorTest failed on Jenkins 1.7 job.

> [Java Performance Tests] Allow specifying of test configuration with 
> Javascript
> ---
>
> Key: QPID-4103
> URL: https://issues.apache.org/jira/browse/QPID-4103
> Project: Qpid
>  Issue Type: Task
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Alex Rudyy
>Assignee: Philip Harvey
> Fix For: 0.17
>
> Attachments: 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch, 
> 0001-QPID-4103-Java-Performance-Tests-Allow-specifying-of.patch
>
>
> Add support for JavaScript configuration into Performance Test Framework in 
> order to generate JSON test configuration from provided javascript file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request: qpidd refactor

[Gordon Sim]

> On July 11, 2012, 7:28 p.m., Kenneth Giusti wrote:
> > /trunk/qpid/cpp/src/qpid/broker/Queue.cpp, line 269
> > 
> >
> > Why pass msg by copy instead of reference?
> 
> Gordon Sim wrote:
> The intention was to enforce the fact that each 'queue' can only operate 
> on a copy, and not affect the message as passed along to other 'queues'. I 
> could also make it a const reference, which might make more sense as the 
> queue implementation can then copy at the point it wants. (That is currently 
> complicated by the fact that we may want to modify the message before we 
> write it to disk, which happens before we add it to Messages, which is where 
> the 'canonical' copy of the message on this queue will be held. However, 
> copying is at present a relatively cheap thing unless there are very many 
> annotations).
> 
> I'll see if I can change to a const reference easily. Good comment!

I did look at doing this, but it required taking a copy in the Queue::deliver() 
method anyway, as at present enqueue may modify the message (before storing it) 
and the modified message should then be passed tp push(). Seems in fact 
simpler/clearer/cleaner at present to leave the deliver() method as taking a 
copy in my view.


- Gordon


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


On July 17, 2012, 12:38 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5833/
> ---
> 
> (Updated July 17, 2012, 12:38 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Kenneth Giusti.
> 
> 
> Description
> ---
> 
> == Background ==
> 
> I've been looking at what would be required to get AMQP 1.0 support in
> the qpidd broker (using proton-c). In that context I felt there was a
> need to refactor the broker code, particularly that part that would be
> shared between different protocol versions. Part of the motivation was
> clearer separation of 0-10 specific logic, so that 1.0 logic could be
> introduced as an alternative. However part of it was also simply the
> recognition of some long-standing problems that we have never stopped
> to address.
> 
> So, here is a patch representing my ideas on what is needed. This is
> already a little stale (patch was generated against r1331342) and
> needs a rebase. However I think the basic ideas involved are clear
> enough that it would be worth getting some early feedback.
> 
> == Key Changes ==
> 
> qpid::broker::Message
> 
> This is now supposed to be a protocol neutral representation of a
> message. It no longer exposes qpid::framing::FrameSet. It can be based
> on data received in different encodings (this patch only includes the
> existing 0-10 encoding).
> 
> The immutable, sharable state is separated from the mutable
> queue-specific state. Messages themselves are no longer held through a
> shared pointer but are passed by reference or copied if needed. The
> immutable state (essentially the data as received) *is* still shared
> and referenced internally through an intrusive pointer. There is no
> longer a message level lock. A message instance is 'owned' by
> someother entity (usually the queue it is on) which controls
> concurrent access/modification if necessary.
> 
> The persistence context is a separate part of the message
> also. Currently that can be shared between two message instances if
> desired.
> 
> qpid::broker::Messages
> 
> Switched from using qpid::broker::QueuedMessage (which relied on
> shared pointer to message itself and made sequence number the explicit
> - and only - way to refer to a specific message) to using modified
> Message class directly and a new qpid::broker::QueueCursor.
> 
> The cursor is opaque outside the Messages implementation to which it
> relates. It provides a way to refer to a specific message (without
> directly using sequence number, though at present that is what is used
> 'under the covers') and/or to track progress through a sequence of
> messages (for consumers or other iterating entities).
> 
> I.e. its an iterator to a Message within its containing Messages
> instance that is not invalidated by changes to that container.
> 
> A Messages instance *owns* the Message instances within it. Other
> classes access this through a reference or (raw) pointer, or if needed
> copy it (the immutable part can be - and is - safely shared).
> 
> The codepath for browse/consume is a lot more unified now. You use a
> cursor and call Messages::next() in each case. This also lays the
> foundation for selectors.
> 
> The simplified Messages interface led to a simplied
> MessageDistributor. There is still a l

Re: Review Request: qpidd refactor

[Gordon Sim]

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

(Updated July 17, 2012, 12:38 p.m.)


Review request for qpid, Alan Conway and Kenneth Giusti.


Changes
---

Rebased (to r1362014). Removed irrelevant changes (to cluster and to Codec 
interface). Fixed xml exchange.

Current status: there is one intermittent failure in the ha tests 
(ha_tests.LongTests.test_failover_send_receive); some unit tests still 
disabled; all other tests are passing reliably.


Description
---

== Background ==

I've been looking at what would be required to get AMQP 1.0 support in
the qpidd broker (using proton-c). In that context I felt there was a
need to refactor the broker code, particularly that part that would be
shared between different protocol versions. Part of the motivation was
clearer separation of 0-10 specific logic, so that 1.0 logic could be
introduced as an alternative. However part of it was also simply the
recognition of some long-standing problems that we have never stopped
to address.

So, here is a patch representing my ideas on what is needed. This is
already a little stale (patch was generated against r1331342) and
needs a rebase. However I think the basic ideas involved are clear
enough that it would be worth getting some early feedback.

== Key Changes ==

qpid::broker::Message

This is now supposed to be a protocol neutral representation of a
message. It no longer exposes qpid::framing::FrameSet. It can be based
on data received in different encodings (this patch only includes the
existing 0-10 encoding).

The immutable, sharable state is separated from the mutable
queue-specific state. Messages themselves are no longer held through a
shared pointer but are passed by reference or copied if needed. The
immutable state (essentially the data as received) *is* still shared
and referenced internally through an intrusive pointer. There is no
longer a message level lock. A message instance is 'owned' by
someother entity (usually the queue it is on) which controls
concurrent access/modification if necessary.

The persistence context is a separate part of the message
also. Currently that can be shared between two message instances if
desired.

qpid::broker::Messages

Switched from using qpid::broker::QueuedMessage (which relied on
shared pointer to message itself and made sequence number the explicit
- and only - way to refer to a specific message) to using modified
Message class directly and a new qpid::broker::QueueCursor.

The cursor is opaque outside the Messages implementation to which it
relates. It provides a way to refer to a specific message (without
directly using sequence number, though at present that is what is used
'under the covers') and/or to track progress through a sequence of
messages (for consumers or other iterating entities).

I.e. its an iterator to a Message within its containing Messages
instance that is not invalidated by changes to that container.

A Messages instance *owns* the Message instances within it. Other
classes access this through a reference or (raw) pointer, or if needed
copy it (the immutable part can be - and is - safely shared).

The codepath for browse/consume is a lot more unified now. You use a
cursor and call Messages::next() in each case. This also lays the
foundation for selectors.

The simplified Messages interface led to a simplied
MessageDistributor. There is still a little more to do to clarify
these separate roles (or indeed perhaps unify them?) but more on that
later.

qpid::broker::amqp_0_10::MessageTransfer

This represents the familiar 0-10 encoding of a message. This class is
broadly similar to the old Message class, based on a FrameSet. However
it represents the shared and essentially immutable state. The
sendHeader() method now explicitly takes a copy of the original
headers and adds to it or otherwise modifies it if needed (e.g. for
redelivered flag, ttl, annotations etc).

[Ideally I'd like to move more of the 0-10 specific classes out of
qpid::broker and into qpid::broker::amqp_0_10, but that has no
functional relevance so I've left existing classes alone for now.]

qpid::broker::Consumer

The deliver() method now takes a QueueCursor (representing a 'handle'
to this message for use in subsequent operations such as accept,
relese etc) and a *constant reference* to the Message itself
(i.e. consumers can't alter the state of the message on the queue
directly, but only through operations on the queue itself).

qpid::broker::QueueRegistry

The actual queue creation has been pulled out into a base class,
QueueFactory. The actual class of the Queue returned can now be varied
and there are two subclasses in the current patch. The first is a
replacement for the ring policy logic, whereby messages are removed
from the queue in order to keep the queue from growing above a
configured limit.

[jira] [Updated] (QPID-4143) Various tweaks to Java perftest configuration

[Philip Harvey (JIRA)]

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

Philip Harvey updated QPID-4143:


Attachment: 0001-QPID-4143-tweaked-topic-test-config-to-introduce-a-s.patch

attached patch

> Various tweaks to Java perftest configuration
> -
>
> Key: QPID-4143
> URL: https://issues.apache.org/jira/browse/QPID-4143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Performance Tests
>Affects Versions: 0.17
>Reporter: Philip Harvey
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: Future
>
> Attachments: 
> 0001-QPID-4143-tweaked-topic-test-config-to-introduce-a-s.patch
>
>
> The java/perftests/ module is functional, but some of the test JSON/JS files 
> need to be tweaked, and some error reporting should be improved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-4143) Various tweaks to Java perftest configuration

[Philip Harvey (JIRA)]

Philip Harvey created QPID-4143:
---

 Summary: Various tweaks to Java perftest configuration
 Key: QPID-4143
 URL: https://issues.apache.org/jira/browse/QPID-4143
 Project: Qpid
  Issue Type: Improvement
  Components: Java Performance Tests
Affects Versions: 0.17
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor
 Fix For: Future


The java/perftests/ module is functional, but some of the test JSON/JS files 
need to be tweaked, and some error reporting should be improved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-4142) C++ broker connection counting username error when used in ha cluster and auth is EXTERNAL

[Chuck Rolke (JIRA)]

Chuck Rolke created QPID-4142:
-

 Summary: C++ broker connection counting username error when used 
in ha cluster and auth is EXTERNAL
 Key: QPID-4142
 URL: https://issues.apache.org/jira/browse/QPID-4142
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.18
Reporter: Chuck Rolke


In a cluster setup with auth enabled and set to EXTERNAL then the Acl 
connection counting does not get the correct username associated with a 
shadowed connection.

The cluster member that accepts the connection accounts for the correct user 
name. Other cluster members that receive shadow connections see user name 
'anonymous'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org