[jira] [Resolved] (QPID-4147) python-qpid client does not handle interrupts on its selector

[Rafael H. Schloming (JIRA)]

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

Rafael H. Schloming resolved QPID-4147.
---

   Resolution: Fixed
Fix Version/s: 0.19
 Assignee: Rafael H. Schloming

I submitted a fix based on the supplied patch.

> python-qpid client does not handle interrupts on its selector
> -
>
> Key: QPID-4147
> URL: https://issues.apache.org/jira/browse/QPID-4147
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Reporter: Siddhesh Poyarekar
>Assignee: Rafael H. Schloming
> Fix For: 0.19
>
> Attachments: qpid-selector.patch
>
>
> Description of problem:
> python-qpid does not recover if its select() call within the Selector class 
> has been interrupted. This is a problem when setuid() is called after a 
> connection object has been created (hence a new thread has been created).
> Version-Release number of selected component (if applicable):
> python-qpid-0.14
> python-qpid-0.12
> How reproducible:
> Always.
> Steps to Reproduce:
> 1. Create a queue called justin
> 2. Run the following program:
> #!/usr/bin/python
> import os, sys, time
> from qpid.messaging import Connection
> from qpid.messaging import Message
> addressdefault = 'localhost:5672'
> if len(sys.argv) != 2:
> host = addressdefault
> else:
> host = sys.argv[1]
> def do_message():
> conn = Connection(host)
> conn.open()
> sess = conn.session()
> sender = sess.sender('justin')
> message = Message(content='hello world!')
> sender.send(message)
> do_message()
> try:
> os.setuid(500)
> except:
> print "Exception has happened"
> pass
> do_message()
>   
> Actual results:
> Traceback:
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap
> self.run()
>   File "/usr/lib64/python2.4/threading.py", line 422, in run
> self.__target(*self.__args, **self.__kwargs)
>   File "/usr/lib/python2.4/site-packages/qpid/selector.py", line 119, in run
> rd, wr, ex = select(self.reading, self.writing, (), timeout)
> error: (4, 'Interrupted system call')
> Expected results:
> No traceback.

--
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] [Comment Edited] (QPID-4069) DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession occasionally seen to fail on CI

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-4069 at 7/30/12 9:35 PM:
---

Phil, could you review please?

  was (Author: k-wall):
Phil, could yo review please?
  
> DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession 
> occasionally seen to fail on CI
> 
>
> Key: QPID-4069
> URL: https://issues.apache.org/jira/browse/QPID-4069
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Affects Versions: 0.17
>Reporter: Keith Wall
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.17
>
>
> As with build 311.
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/311/jdk=JDK%201.6%20%28latest%29,label=Ubuntu,profile=java-bdb.0-9-1/testReport/junit/org.apache.qpid.systest.disttest.clientonly/DistributedClientTest/testClientFailsToCreateProducerUsingInvalidSession/
> {code}
> Error Message
> No message received from control queue
> Stacktrace
> junit.framework.AssertionFailedError: No message received from control queue
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:72)
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:64)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.sendCommandAndValidateResponse(DistributedClientTest.java:216)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:249)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:258)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.setUp(DistributedClientTest.java:82)
>   at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:239)
>   at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:137)
> {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] [Assigned] (QPID-4069) DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession occasionally seen to fail on CI

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-4069:


Assignee: Philip Harvey  (was: Keith Wall)

Phil, could yo review please?

> DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession 
> occasionally seen to fail on CI
> 
>
> Key: QPID-4069
> URL: https://issues.apache.org/jira/browse/QPID-4069
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Affects Versions: 0.17
>Reporter: Keith Wall
>Assignee: Philip Harvey
>Priority: Minor
> Fix For: 0.17
>
>
> As with build 311.
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/311/jdk=JDK%201.6%20%28latest%29,label=Ubuntu,profile=java-bdb.0-9-1/testReport/junit/org.apache.qpid.systest.disttest.clientonly/DistributedClientTest/testClientFailsToCreateProducerUsingInvalidSession/
> {code}
> Error Message
> No message received from control queue
> Stacktrace
> junit.framework.AssertionFailedError: No message received from control queue
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:72)
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:64)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.sendCommandAndValidateResponse(DistributedClientTest.java:216)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:249)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:258)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.setUp(DistributedClientTest.java:82)
>   at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:239)
>   at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:137)
> {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] [Comment Edited] (QPID-4069) DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession occasionally seen to fail on CI

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-4069 at 7/30/12 9:35 PM:
---

Patch applied (some weeks ago) @ rev 1350722. Extended receive timeout and 
sync'ing after the message to resolve the test only issue..



  was (Author: k-wall):
Patch applied (some weeks ago) @ rev 1350722. Extended receive timeout and 
sync'ing after the message to resolve the test onluy issue..


  
> DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession 
> occasionally seen to fail on CI
> 
>
> Key: QPID-4069
> URL: https://issues.apache.org/jira/browse/QPID-4069
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Affects Versions: 0.17
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: 0.17
>
>
> As with build 311.
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/311/jdk=JDK%201.6%20%28latest%29,label=Ubuntu,profile=java-bdb.0-9-1/testReport/junit/org.apache.qpid.systest.disttest.clientonly/DistributedClientTest/testClientFailsToCreateProducerUsingInvalidSession/
> {code}
> Error Message
> No message received from control queue
> Stacktrace
> junit.framework.AssertionFailedError: No message received from control queue
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:72)
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:64)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.sendCommandAndValidateResponse(DistributedClientTest.java:216)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:249)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:258)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.setUp(DistributedClientTest.java:82)
>   at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:239)
>   at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:137)
> {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-4069) DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession occasionally seen to fail on CI

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-4069:
--

Patch applied (some weeks ago) @ rev 1350722. Extended receive timeout and 
sync'ing after the message to resolve the test onluy issue..



> DistributedClientTest.testClientFailsToCreateProducerUsingInvalidSession 
> occasionally seen to fail on CI
> 
>
> Key: QPID-4069
> URL: https://issues.apache.org/jira/browse/QPID-4069
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Affects Versions: 0.17
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: 0.17
>
>
> As with build 311.
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/311/jdk=JDK%201.6%20%28latest%29,label=Ubuntu,profile=java-bdb.0-9-1/testReport/junit/org.apache.qpid.systest.disttest.clientonly/DistributedClientTest/testClientFailsToCreateProducerUsingInvalidSession/
> {code}
> Error Message
> No message received from control queue
> Stacktrace
> junit.framework.AssertionFailedError: No message received from control queue
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:72)
>   at 
> org.apache.qpid.systest.disttest.clientonly.ControllerQueue.getNext(ControllerQueue.java:64)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.sendCommandAndValidateResponse(DistributedClientTest.java:216)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:249)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.createTestSession(DistributedClientTest.java:258)
>   at 
> org.apache.qpid.systest.disttest.clientonly.DistributedClientTest.setUp(DistributedClientTest.java:82)
>   at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:239)
>   at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:137)
> {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

Re: 0.18 inclusion request

[Rajith Attapattu]

Looks like I dropped the ball on this.
Anyways I changed the name of the system property to "
qpid.session.legacy_exception_behaviour" and made sure it completely
reserved the current behaviour to the existing behaviour when switched
on.

I have now ported all required commits to the 0.18 branch.

Rajith

On Wed, Jul 18, 2012 at 7:57 AM, Rajith Attapattu  wrote:
> Robbie,
>
> I agree that the system prop doesn't completely restore the old behaviour.
> That was actually a mistake on my part. I intend to correct it shortly.
>
> I actually like your suggested name :).
> So let me change it to qpid.session_legacy_exception_behaviour
>
> Regards,
>
> Rajith
>
> On Wed, Jul 18, 2012 at 6:03 AM, Robbie Gemmell
>  wrote:
>> I don't particularly like the name, but as its not really intended for
>> regular use it doesnt necessarily bother me enough to change it. I might
>> have gone for 'legacy session exception behaviour' or something to that
>> effect.
>>
>> I am more interested that its use doesn't entirely accomplish what I
>> suggested adding it for though, since only some of the new behaviour is
>> reversed by its use. I think the new behaviour seems reasonable, but I
>> still believe an interim ability to fully restore the old (broken,
>> admittedly) behaviour if required be would be prudent given how long it has
>> been that way (even supposing it meant a second system property to allow
>> choosing whether you get some or all of the new behaviour).
>>
>> Robbie
>>
>> On 18 July 2012 00:13, 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-unsubscribe@qpid.apache.**org
 For additional commands, e-mail: dev-h...@qpid.apache.org



>>> --**--**-
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@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] [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

> [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-Refactor-test-approach-to-avoid-comparing-.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] [Closed] (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 closed QPID-4103.



> [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-Refactor-test-approach-to-avoid-comparing-.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] [Resolved] (QPID-4170) JMX threads can spin in the Queue MBean if there is a failure when viewing message content

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-4170.
--

Resolution: Fixed

Reviewed, no comments.

> JMX threads can spin in the Queue MBean if there is a failure when viewing 
> message content
> --
>
> Key: QPID-4170
> URL: https://issues.apache.org/jira/browse/QPID-4170
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Keith Wall
>Priority: Critical
> Fix For: 0.19
>
>
> During the work on QPID-4164 it was found that JMX threads can spin in the 
> Queue MBean if they fail when viewing message content, looping down into the 
> message and back store asking for content which will never be returned. These 
> threads will never stop spinning, and will consume CPU resources and 
> introduce additional/unnecessary resource contention within the store layer.
> The view content method of the Queue MBean should be updated to avoid this 
> possibility.

--
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-4157) HA setting status to CATCHUP to early.

[Alan Conway (JIRA)]

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

Alan Conway resolved QPID-4157.
---

Resolution: Fixed

Fixed r1363520

> HA setting status to CATCHUP to early.
> --
>
> Key: QPID-4157
> URL: https://issues.apache.org/jira/browse/QPID-4157
> Project: Qpid
>  Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>


--
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-4157) HA setting status to CATCHUP to early.

[Alan Conway (JIRA)]

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

Alan Conway reassigned QPID-4157:
-

Assignee: Alan Conway

> HA setting status to CATCHUP to early.
> --
>
> Key: QPID-4157
> URL: https://issues.apache.org/jira/browse/QPID-4157
> Project: Qpid
>  Issue Type: Bug
>Reporter: Alan Conway
>Assignee: Alan Conway
>


--
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-4130) Remove use of intrusive_ptr::reset in ha/Primary.cpp, not supported by older boost versions.

[Alan Conway (JIRA)]

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

Alan Conway resolved QPID-4130.
---

Resolution: Fixed

Fixed in r1360218

> Remove use of intrusive_ptr::reset in ha/Primary.cpp, not supported by older 
> boost versions.
> 
>
> Key: QPID-4130
> URL: https://issues.apache.org/jira/browse/QPID-4130
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18
>
>
> Remove use of intrusive_ptr::reset in ha/Primary.cpp, not supported by older 
> boost versions.

--
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-4171) persistent messages from a non-transactional session can be enqueued out of order

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-4171:
--

Renamed JIRA to indicate only persistent messages can be enqueued out of order, 
transient messages will always have an immediate future assigned and will thus 
enqueue in-order. It is possible for transient messages to overtake persistent 
messages, but thats is allowable (though we should have given people the option 
to prevent it).

Attached are some helpful scribbles for anyone working on this. It includes a 
trivial potential fix (&& !persistent), along with some dead code removal, and 
addition of a noddy system property to escape the previously mentioned 
'transient can overtake persistent' behaviour when mixing delivery modes. It 
semi-duplicates the existing addFuture() method because thats used by more than 
just the enqueue methods for things that care nothing of whether its persistent 
message or whether strict ordering is desired, so it seemed like it would be a 
bit nasty just feeding default parameter values to a shared implementation. 
This isn't really a patch as such, it hasn't even been compiled properly 
nevermind tested, but I think it should work :)

> persistent messages from a non-transactional session can be enqueued out of 
> order
> -
>
> Key: QPID-4171
> URL: https://issues.apache.org/jira/browse/QPID-4171
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store
>Affects Versions: 0.16, 0.18, 0.19
>Reporter: Keith Wall
>Assignee: Keith Wall
> Attachments: QPID-4171-scribbles.txt
>
>
> A defect in AsyncAutoCommitTransaction means that occasionally messages 
> delivered by a non-transactional JMS are seen to be enqueued out-of-order and 
> therefore delivered to a consumer out of the expected order.  
> It is this problem that underlies QPID-4014, although as I think this problem 
> is wider than ConflationQueues, I am raising this separately.

--
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-4171) persistent messages from a non-transactional session can be enqueued out of order

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-4171:
-

Attachment: QPID-4171-scribbles.txt

> persistent messages from a non-transactional session can be enqueued out of 
> order
> -
>
> Key: QPID-4171
> URL: https://issues.apache.org/jira/browse/QPID-4171
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store
>Affects Versions: 0.16, 0.18, 0.19
>Reporter: Keith Wall
>Assignee: Keith Wall
> Attachments: QPID-4171-scribbles.txt
>
>
> A defect in AsyncAutoCommitTransaction means that occasionally messages 
> delivered by a non-transactional JMS are seen to be enqueued out-of-order and 
> therefore delivered to a consumer out of the expected order.  
> It is this problem that underlies QPID-4014, although as I think this problem 
> is wider than ConflationQueues, I am raising this separately.

--
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-4171) persistent messages from a non-transactional session can be enqueued out of order

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-4171:
-

Summary: persistent messages from a non-transactional session can be 
enqueued out of order  (was: Messages from a non-transactional session can be 
enqueued out of order)

> persistent messages from a non-transactional session can be enqueued out of 
> order
> -
>
> Key: QPID-4171
> URL: https://issues.apache.org/jira/browse/QPID-4171
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store
>Affects Versions: 0.16, 0.18, 0.19
>Reporter: Keith Wall
>Assignee: Keith Wall
>
> A defect in AsyncAutoCommitTransaction means that occasionally messages 
> delivered by a non-transactional JMS are seen to be enqueued out-of-order and 
> therefore delivered to a consumer out of the expected order.  
> It is this problem that underlies QPID-4014, although as I think this problem 
> is wider than ConflationQueues, I am raising this separately.

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

Trivial 0.18 merge requested (logging statement changes)

[Alan Conway]

I'd like to merge to 0.18:
https://issues.apache.org/jira/browse/QPID-4175

It's just edits to log statements and log levels to give a more
organized set of messages for debugging.


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

[jira] [Commented] (QPID-4175) HA code rationalize logging

[Alan Conway (JIRA)]

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

Alan Conway commented on QPID-4175:
---

Committed to trunk r1367231
Request 0.18 merge

> HA code rationalize logging
> ---
>
> Key: QPID-4175
> URL: https://issues.apache.org/jira/browse/QPID-4175
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.17
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Minor
> Fix For: 0.18
>
>
> Clean up and rationalize log messages and levels.
> notice: Major broker-level events: connecting, failing-over, primary active, 
> backup ready.
> info: Major queue level events: subscriptions ready, replicators created etc.
> debug: Detailed replication events: accept/reject conections, details of 
> queue replication protocol.
> trace: dumping raw QMF messages

--
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-4175) HA code rationalize logging

[Alan Conway (JIRA)]

Alan Conway created QPID-4175:
-

 Summary: HA code rationalize logging
 Key: QPID-4175
 URL: https://issues.apache.org/jira/browse/QPID-4175
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.17
Reporter: Alan Conway
Assignee: Alan Conway
Priority: Minor
 Fix For: 0.18


Clean up and rationalize log messages and levels.

notice: Major broker-level events: connecting, failing-over, primary active, 
backup ready.
info: Major queue level events: subscriptions ready, replicators created etc.
debug: Detailed replication events: accept/reject conections, details of queue 
replication protocol.
trace: dumping raw QMF messages


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

[RESULT] [VOTE] Proton mailing list

[Rafael Schloming]

This vote is now closed. The vote passes with 7 +1 votes and one
non-binding -1 vote.

--Rafael

On Wed, 2012-07-25 at 15:05 -0400, Rafael Schloming wrote:
> Hi Everyone,
> 
> There's been a lot of good discussion about proton on the dev list,
> however, despite my encouragement, many interested parties do not follow
> the qpid dev list and instead email me directly as a matter of
> convenience. It's my belief that a proton mailing list would help
> encourage these parties to participate more openly and foster better
> communication between all the various users of proton both inside and
> outside of qpid. To that end I'd like to propose creating
> "pro...@qpid.apache.org".
> 
> [ ] Yes, create pro...@qpid.apache.org
> [ ] No, people who don't follow dev@qpid.apache.org shouldn't get a say.
> 
> --Rafael
> 
> 
> -
> 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

[RESULT] [VOTE] Proton JIRA project

[Rafael Schloming]

This vote is now closed. The vote passes with 12 +1 votes and one -1
vote.

Just to avoid any possible confusion, I'd like to reiterate that this
vote is on the infrastructure matter of a separate JIRA instance only
and has no bearing on any of the other points mentioned in Justin's
dissenting vote.

--Rafael

On Wed, 2012-07-25 at 13:34 -0400, Rafael Schloming wrote:
> Hi Everyone,
> 
> I believe this has been mentioned in a few threads now, but in order to
> release Proton, it needs to have it's own JIRA project. (I tried
> managing this with a component within the Qpid JIRA project, but
> versions are scoped to projects not components, so this simply won't
> work.) As I'd like to be able to do a release sooner rather than later,
> I'd like to get the JIRA project in place ASAP. (The formal vote is
> required for infrastructure.)
> 
> [ ] Yes, create a JIRA project for Proton.
> [ ] No, bah, humbug, Proton can suck it.
> 
> --Rafael
> 
> 
> 
> -
> 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-4174) Allow getting information about established TCP connection in Java client

[Rajith Attapattu (JIRA)]

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

Rajith Attapattu commented on QPID-4174:


I'm not too keen about this approach.

QMF has more details (ex process name, pid etc) at it's disposal. A monitoring 
application could use this already available information to correlate 
connections to events.
If QMF doesn't send this information in events already, then it should probably 
do it.

At the moment qpid.client_process is set as a jvm argument. This could be 
easily included on a per connection basis as well.
That way you could give more meaningful identifier for each connection and then 
use them in monitoring applications.

> Allow getting information about established TCP connection in Java client
> -
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Priority: Minor
>  Labels: patch
> Attachments: 0001_QPID-4174_AllowTCPconn-info.patch
>
>
> Java client does not offer a method to print out active TCP connection (like 
> string "127.0.0.1:12345->127.0.0.1:5672"). Pure JMS API does not offer so at 
> all, checking sources of Java client shows the underlying TCP socket is kept 
> in a private member of a class that does not offer a (readonly) access to the 
> member.
> The enhancement is meaningful for management purposes to detect connectivity. 
> If the Java client listens for QMF updates from the qpid broker, it get 
> events like "127.0.0.1:12345->127.0.0.1:5672 disconnected". But currently it 
> can not match the event to its local connection(s) as it doesn't know them.
> I am attaching a simple patch file such that AMQConnection class is extended 
> by getSocketString() method.

--
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 30, 2012, 4 p.m., Kenneth Giusti wrote:
> > /trunk/qpid/cpp/src/qpid/broker/MessageMap.h, line 9
> > 
> >
> > typo

Thanks! How did I miss that...


- Gordon


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


On July 24, 2012, 11:13 a.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5833/
> ---
> 
> (Updated July 24, 2012, 11:13 a.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
> a little stale again (patch was generated against r13613342) and
> needs (yet) another rebase. However it is getting to the point where I'll be 
> asking to commit it soon, so if anyone has feedback, now is the time to give 
> it!
> 
> == 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

[jira] [Updated] (QPID-4124) AMQChannel checkTransactionStatus logging not useful because it uses default Object.toString

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-4124:
-

Attachment: 0001-QPID-4124-Improved-logging-that-is-produced-when-the.patch

Attached patch allowing to have either operational or standard logs to avoid 
duplication in transaction timeout functionality on 0-9.x and 0.10 code paths. 

> AMQChannel checkTransactionStatus logging not useful because it uses default 
> Object.toString
> 
>
> Key: QPID-4124
> URL: https://issues.apache.org/jira/browse/QPID-4124
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.18
>Reporter: Philip Harvey
>Assignee: Philip Harvey
>Priority: Trivial
> Fix For: Future
>
> Attachments: 
> 0001-QPID-4124-Improved-logging-that-is-produced-when-the.patch, 
> 0001-QPID-4124-log-output-should-use-LogSubject.toLogStri.patch
>
>
> In AMQChannel, code such as 
> _logger.warn("IDLE TRANSACTION ALERT " + _logSubject.toString() ...
> should be replaced by 
> _logger.warn("IDLE TRANSACTION ALERT " + _logSubject.toLogString() ...
> because the first example uses Object.toString, which is not very useful for 
> logging.

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

[Kenneth Giusti]

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

Ship it!


Ship It!


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


typo


- Kenneth Giusti


On July 24, 2012, 11:13 a.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5833/
> ---
> 
> (Updated July 24, 2012, 11:13 a.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
> a little stale again (patch was generated against r13613342) and
> needs (yet) another rebase. However it is getting to the point where I'll be 
> asking to commit it soon, so if anyone has feedback, now is the time to give 
> it!
> 
> == 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

Re: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[eugene]

fun :)

googling does not help so far also..





--
View this message in context: 
http://apache-qpid-developers.2158895.n2.nabble.com/qpidd-0-14-Kerberos-Active-Directory-on-Windows-2003-Server-tp7581381p7581451.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

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

[jira] [Commented] (QPID-4164) Management moveMessage/copyMessage functions fail to properly move/copy the message if the message has been loaded from the store at Broker startup

[Justin Ross (JIRA)]

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

Justin Ross commented on QPID-4164:
---

Reviewed by Keith, Philip, and Robbie.  Approved for 0.18.

> Management moveMessage/copyMessage functions fail to properly move/copy the 
> message if the message has been loaded from the store at Broker startup
> ---
>
> Key: QPID-4164
> URL: https://issues.apache.org/jira/browse/QPID-4164
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store, Java Management : 
> JMX Console
>Affects Versions: 0.16, 0.18
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Critical
> Fix For: 0.19
>
> Attachments: 
> QPID-4164-MaxDeliveryCountTest-should-restart-broker-after-enqueue.patch
>
>
> The JMX moveMessage/copyMessage functions fail to properly move/copy the 
> message if the message has been recovered from the store at Broker startup. 
> The Broker permanently loses the message's payload.
> If an operator subsequently tries to view the problematic message with the 
> Management interfaces, a Broker thread will be put into an infinite loop and 
> this will require a Broker restart.
> This problem does not affect messages sent during the lifetime of the 
> Broker's execution (they can be moved or copied as normal).  The existence of 
> messages with lost payload within the Broker does not affect the flight of 
> other messages through the Broker.

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

Request for inclusion in 0.18

[Robbie Gemmell]

Hi Justin,

I would like to request that the following commits be considered for
inclusion in 0.18:

https://issues.apache.org/jira/browse/QPID-4164
http://svn.apache.org/viewvc?view=revision&revision=1366339
http://svn.apache.org/viewvc?view=revision&revision=1365832
http://svn.apache.org/viewvc?view=revision&revision=1367095

The above commits fix / add tests for an issue whereby moving/copying
persistent messages between queues (either manually via the management
interface, or automatically using a feature such as maximum-redelivery on
queues configured with with DLQs) can result in loss of the payload if the
message was originally recovered from the message store. The change is very
isolated (to the message stores) and trivial as-is but would look even
smaller if we hadn't inverted the meaning of a boolean.

https://issues.apache.org/jira/browse/QPID-4170
http://svn.apache.org/viewvc?view=revision&revision=1367084

The above commit fixes an issue where JMX management threads can enter a
infite loop when viewing the content of messages affected by the issue
above, consuming CPU resources and creating additional lock contention in
the message store. The change is again very isolated (to the Queue MBean)
and trivial.

The changes were made either by Keith, Phil, or myself, and have then been
reviewed by at least one but usually both of the others.

Robbie

Re: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[Gordon Sim]

On 07/30/2012 02:34 PM, eugene wrote:

I don't think this is true,


Very possible, I'm certainly no expert...


see this:

http://www.opensubscriber.com/message/kerbe...@mit.edu/14923168.html

This seems normal, except that the second entry is not created of course..


...so if there is no mapping in the domain_realms section, it will try 
the default realm (which I assume is correctly specified). The question 
would be then why it was unable to obtain a ticket for that domain, 
which as I understand that post would be listed also by klist if obtained.


I don't know where the logs for the KDC on Active Directory are, but 
they may shed some light.




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

[jira] [Commented] (QPID-4164) Management moveMessage/copyMessage functions fail to properly move/copy the message if the message has been loaded from the store at Broker startup

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-4164:
--

Hi Phil, no comments on your patch.  It has been applied to trunk.

> Management moveMessage/copyMessage functions fail to properly move/copy the 
> message if the message has been loaded from the store at Broker startup
> ---
>
> Key: QPID-4164
> URL: https://issues.apache.org/jira/browse/QPID-4164
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store, Java Management : 
> JMX Console
>Affects Versions: 0.16, 0.18
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Critical
> Fix For: 0.19
>
> Attachments: 
> QPID-4164-MaxDeliveryCountTest-should-restart-broker-after-enqueue.patch
>
>
> The JMX moveMessage/copyMessage functions fail to properly move/copy the 
> message if the message has been recovered from the store at Broker startup. 
> The Broker permanently loses the message's payload.
> If an operator subsequently tries to view the problematic message with the 
> Management interfaces, a Broker thread will be put into an infinite loop and 
> this will require a Broker restart.
> This problem does not affect messages sent during the lifetime of the 
> Broker's execution (they can be moved or copied as normal).  The existence of 
> messages with lost payload within the Broker does not affect the flight of 
> other messages through the Broker.

--
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-4164) Management moveMessage/copyMessage functions fail to properly move/copy the message if the message has been loaded from the store at Broker startup

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-4164.
--

Resolution: Fixed
  Assignee: Keith Wall  (was: Robbie Gemmell)

> Management moveMessage/copyMessage functions fail to properly move/copy the 
> message if the message has been loaded from the store at Broker startup
> ---
>
> Key: QPID-4164
> URL: https://issues.apache.org/jira/browse/QPID-4164
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Broker BDB Store, Java Management : 
> JMX Console
>Affects Versions: 0.16, 0.18
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Critical
> Fix For: 0.19
>
> Attachments: 
> QPID-4164-MaxDeliveryCountTest-should-restart-broker-after-enqueue.patch
>
>
> The JMX moveMessage/copyMessage functions fail to properly move/copy the 
> message if the message has been recovered from the store at Broker startup. 
> The Broker permanently loses the message's payload.
> If an operator subsequently tries to view the problematic message with the 
> Management interfaces, a Broker thread will be put into an infinite loop and 
> this will require a Broker restart.
> This problem does not affect messages sent during the lifetime of the 
> Broker's execution (they can be moved or copied as normal).  The existence of 
> messages with lost payload within the Broker does not affect the flight of 
> other messages through the Broker.

--
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-4170) JMX threads can spin in the Queue MBean if there is a failure when viewing message content

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-4170:
-

Status: Ready To Review  (was: In Progress)

> JMX threads can spin in the Queue MBean if there is a failure when viewing 
> message content
> --
>
> Key: QPID-4170
> URL: https://issues.apache.org/jira/browse/QPID-4170
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.19
>
>
> During the work on QPID-4164 it was found that JMX threads can spin in the 
> Queue MBean if they fail when viewing message content, looping down into the 
> message and back store asking for content which will never be returned. These 
> threads will never stop spinning, and will consume CPU resources and 
> introduce additional/unnecessary resource contention within the store layer.
> The view content method of the Queue MBean should be updated to avoid this 
> possibility.

--
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-4170) JMX threads can spin in the Queue MBean if there is a failure when viewing message content

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-4170:
--

Fix and tests added in 
http://svn.apache.org/viewvc?view=revision&revision=1367084

> JMX threads can spin in the Queue MBean if there is a failure when viewing 
> message content
> --
>
> Key: QPID-4170
> URL: https://issues.apache.org/jira/browse/QPID-4170
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Critical
> Fix For: 0.19
>
>
> During the work on QPID-4164 it was found that JMX threads can spin in the 
> Queue MBean if they fail when viewing message content, looping down into the 
> message and back store asking for content which will never be returned. These 
> threads will never stop spinning, and will consume CPU resources and 
> introduce additional/unnecessary resource contention within the store layer.
> The view content method of the Queue MBean should be updated to avoid this 
> possibility.

--
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-4170) JMX threads can spin in the Queue MBean if there is a failure when viewing message content

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell reassigned QPID-4170:


Assignee: Keith Wall  (was: Robbie Gemmell)

Keith, could you review this change please?

> JMX threads can spin in the Queue MBean if there is a failure when viewing 
> message content
> --
>
> Key: QPID-4170
> URL: https://issues.apache.org/jira/browse/QPID-4170
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18
>Reporter: Robbie Gemmell
>Assignee: Keith Wall
>Priority: Critical
> Fix For: 0.19
>
>
> During the work on QPID-4164 it was found that JMX threads can spin in the 
> Queue MBean if they fail when viewing message content, looping down into the 
> message and back store asking for content which will never be returned. These 
> threads will never stop spinning, and will consume CPU resources and 
> introduce additional/unnecessary resource contention within the store layer.
> The view content method of the Queue MBean should be updated to avoid this 
> possibility.

--
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: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[eugene]

I don't think this is true, see this:

http://www.opensubscriber.com/message/kerbe...@mit.edu/14923168.html

This seems normal, except that the second entry is not created of course..



--
View this message in context: 
http://apache-qpid-developers.2158895.n2.nabble.com/qpidd-0-14-Kerberos-Active-Directory-on-Windows-2003-Server-tp7581381p7581442.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

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

[jira] [Updated] (QPID-4174) Allow getting information about established TCP connection in Java client

[Pavel Moravec (JIRA)]

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

Pavel Moravec updated QPID-4174:


Attachment: 0001_QPID-4174_AllowTCPconn-info.patch

Proposed enhancement patch.

> Allow getting information about established TCP connection in Java client
> -
>
> Key: QPID-4174
> URL: https://issues.apache.org/jira/browse/QPID-4174
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: 0.14
>Reporter: Pavel Moravec
>Priority: Minor
>  Labels: patch
> Attachments: 0001_QPID-4174_AllowTCPconn-info.patch
>
>
> Java client does not offer a method to print out active TCP connection (like 
> string "127.0.0.1:12345->127.0.0.1:5672"). Pure JMS API does not offer so at 
> all, checking sources of Java client shows the underlying TCP socket is kept 
> in a private member of a class that does not offer a (readonly) access to the 
> member.
> The enhancement is meaningful for management purposes to detect connectivity. 
> If the Java client listens for QMF updates from the qpid broker, it get 
> events like "127.0.0.1:12345->127.0.0.1:5672 disconnected". But currently it 
> can not match the event to its local connection(s) as it doesn't know them.
> I am attaching a simple patch file such that AMQConnection class is extended 
> by getSocketString() method.

--
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-4174) Allow getting information about established TCP connection in Java client

[Pavel Moravec (JIRA)]

Pavel Moravec created QPID-4174:
---

 Summary: Allow getting information about established TCP 
connection in Java client
 Key: QPID-4174
 URL: https://issues.apache.org/jira/browse/QPID-4174
 Project: Qpid
  Issue Type: Improvement
  Components: Java Client
Affects Versions: 0.14
Reporter: Pavel Moravec
Priority: Minor


Java client does not offer a method to print out active TCP connection (like 
string "127.0.0.1:12345->127.0.0.1:5672"). Pure JMS API does not offer so at 
all, checking sources of Java client shows the underlying TCP socket is kept in 
a private member of a class that does not offer a (readonly) access to the 
member.


The enhancement is meaningful for management purposes to detect connectivity. 
If the Java client listens for QMF updates from the qpid broker, it get events 
like "127.0.0.1:12345->127.0.0.1:5672 disconnected". But currently it can not 
match the event to its local connection(s) as it doesn't know them.

I am attaching a simple patch file such that AMQConnection class is extended by 
getSocketString() method.


--
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: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[Gordon Sim]

On 07/30/2012 01:51 PM, eugene wrote:

There is one more interesting thing that confuses me now.

After I run qpid--pertest and then issue a klist again, I get this:


klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: vmv...@ourdomain.com

Valid starting ExpiresService principal
07/30/12 08:46:42  07/30/12 18:46:38  krbtgt/ourdomain@ourdomain.com
 renew until 07/31/12 08:46:42
07/30/12 08:47:05  07/30/12 18:46:38  qpidd/vmvmrg@
 renew until 07/31/12 08:46:42


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Now I am pretty lost :) Where did the second entry came from? I have not
issue any tickets...


That looks like the ticket to use qpidd, but it appears to be missing 
the realm... I think you can fix that by adding a mapping to the 
[domain_realm] section of your /etc/krb5.conf for the vmvmrg host.



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

Re: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[eugene]

There is one more interesting thing that confuses me now.

After I run qpid--pertest and then issue a klist again, I get this:


klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: vmv...@ourdomain.com

Valid starting ExpiresService principal
07/30/12 08:46:42  07/30/12 18:46:38  krbtgt/ourdomain@ourdomain.com
renew until 07/31/12 08:46:42
07/30/12 08:47:05  07/30/12 18:46:38  qpidd/vmvmrg@
renew until 07/31/12 08:46:42


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Now I am pretty lost :) Where did the second entry came from? I have not
issue any tickets...



--
View this message in context: 
http://apache-qpid-developers.2158895.n2.nabble.com/qpidd-0-14-Kerberos-Active-Directory-on-Windows-2003-Server-tp7581381p7581438.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

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

Re: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[eugene]

Hello Gordon,

Ok, so each a time.

I would be glad to provide any details from the KDC(the windows 2003 Server
Box), but I have no idea which or where they are... :( I have enough right
to get them btw.

Here is the command that I run:

vmvmrg - is a user in AD and also (the same String "vmvmrg") is the box that
hosts MRG.

kinit vmvmrg
Password for vmv...@ourdomain.com:
[root@vmvmrg ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: vmv...@ourdomain.com

Valid starting ExpiresService principal
07/30/12 08:08:13  07/30/12 18:08:10  krbtgt/ourdomain@ourdomain.com
renew until 07/31/12 08:08:13


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[root@vmvmrg ~]# /usr/bin/qpid-perftest --mechanism GSSAPI --broker vmvmrg
--count 1

connection-forced: Authentication failed
2012-07-30 08:08:45 warning Broker closed connection: 320,
connection-forced: Authentication failed
[root@vmvmrg ~]#


Thank You,
Eugene.





--
View this message in context: 
http://apache-qpid-developers.2158895.n2.nabble.com/qpidd-0-14-Kerberos-Active-Directory-on-Windows-2003-Server-tp7581381p7581437.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.

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

Re: qpidd 0.14 + Kerberos + Active Directory on Windows 2003 Server

[Gordon Sim]

On 07/27/2012 08:39 AM, eugene wrote:

Well yes I'm sorry I should have been a bit more verbose. Here are the
details:

1. The command that I'm running:

java -Djavax.security.auth.useSubjectCredsOnly=false
-Djava.security.auth.login.config=myjass.conf -Dsun.security.krb5.debug=true
-jar Kerberos.jar

   1.1 I am running it with OpenJDK 1.6_22
   1.2 The myjass.conf looks like this:

  com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true;
  };

2. The keyab file is called krb5.keytab (so I do not need to set the
KRB5_KTNAME variable).

3. Yes the keytab can be read by qpidd (as a matter of fact to make it sure
I just "777"-ed the file anyway)

4. qpid.conf :

auth=yes
realm=OURDOMAIN.COM


Are there any logs available at your KDC that might shed some light?

Do you have the c++ client installed on the machine qpidd is running on? 
If so, it might be worth an experiment to connect with that: kinit for 
your test user then use e.g. qpid-perftest with --mechanism GSSAPI and 
--broker vmvmrg (and --count 1, just for a simple test). If that works, 
it would indicate some configuration issue for JMS, if it doesn't 
(assuming the kinit passes), then it would indicate some problem with 
qpidd authenticating itself.



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

[jira] [Created] (QPID-4173) [Java Broker] disable the subscription state operational logging by default

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPID-4173:


 Summary: [Java Broker] disable the subscription state operational 
logging by default
 Key: QPID-4173
 URL: https://issues.apache.org/jira/browse/QPID-4173
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Affects Versions: 0.16, 0.14, 0.12, 0.10, 0.18
Reporter: Robbie Gemmell
 Fix For: 0.19


Disable the subscription state operational logging by default. 

This logging can be *incredibly* verbose if clients have a low prefetch 
configured, or there is a large backlog of messages on the queue, because the 
state will constantly flip between active and suspended as the buffer becomes 
full,not-full,full,not-full...etc.

We should disable this by default as it tends to drown all the other logging 
that is often more useful. It will still be possible to turn the logging on at 
runtime using the logging management mbean (if the operational logging feature 
is enabled).

--
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-4172) [Java Broker] Virtualhost tasks should reset their thread name upon completion

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPID-4172:


 Summary: [Java Broker] Virtualhost tasks should reset their thread 
name upon completion
 Key: QPID-4172
 URL: https://issues.apache.org/jira/browse/QPID-4172
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: 0.16, 0.15, 0.14, 0.13, 0.12, 0.17, 0.18
Reporter: Robbie Gemmell
Priority: Minor
 Fix For: 0.19


Virtualhost tasks should reset their thread name upon completion should reset 
their thread name upon completion.

We use a ScheduledThreadPoolExecutor for running Virtualhost level tasks such 
as TransactionTimeout, VirtualHostHouseKeepingTask, the UpdateTask, etc. These 
rename the thread at the start of their execution, but do not at the end (as 
explicitly noted in the code, remove the comment) because it will be reset at 
the next tasks execution. This can confusingly result in multiple threads with 
the same name if the pool allocates a task to different threads on subsequent 
executions, so the tasks should restore the original name when they complete to 
avoid confusion.

This will result in the threads always having their generic thread pool name 
except when executing a given task. It might be useful if we could set the base 
name for these threads in some way to make them easier to identify, but this 
may not actually be possible while using a ScheduledThreadPoolExecutor.

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