Re: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
On 6 November 2017 at 14:42, Lorenz Quack wrote: > On Mon, 2017-11-06 at 11:07 +, Lorenz Quack wrote: >> On Mon, 2017-11-06 at 10:14 +, Robbie Gemmell wrote: >> > >> > On 3 November 2017 at 16:58, Rob Godfrey wrote: >> > > >> > > >> > > On 1 November 2017 at 10:16, Lorenz Quack wrote: >> > > >> > > > >> > > > >> > > > Hi, >> > > > >> > > > We noticed a potential problem with the way JMS 2.0 global shared >> > > > durable subscriptions are implemented in the JMS client. The >> > > > implementation was designed, discussed, and implemented in QPIDJMS-220 >> > > > [1]. >> > > > >> > > > When a consumer of a subscription closes the underlying AMQP link is >> > > > not closed but merely detached since the closing of a subscription >> > > > link is used as the signal to unsubscribe the subscription. These >> > > > subscription links remain on the broker until the subscription is >> > > > unsubscribed (detach with close=true) at which point the broker >> > > > discards all links associated with the subscription. >> > > > >> > > > For non-global subscriptions this does not seem to be a problem since >> > > > the clientId is used as the container-id and links are reused if >> > > > possible. >> > > > >> > > > For global subscription on the other hand the client uses a random >> > > > UUID associated with the connection as its own container-id. This >> > > > means that on every new connection a new link is being estblished >> > > > rather than recovering an existing one. Over time these subscription >> > > > links would accumulate on the broker until the subscription is >> > > > unsubscribed. >> > > > >> > > > Since shared durable subscriptions are expected to be long lived this >> > > > raises some concerns with regards to resource exhaustion on the >> > > > broker. An application that would spin up a connection do some work >> > > > on a shared durable global subscription and then disconnect again >> > > > would be "leaking" links. >> > > > >> > > > Due to this concern we plan on disabling shared durable global >> > > > subscriptions for the initial v7 release of Qpid Broker-J. There will >> > > > be a context variable to enable the feature. >> > > > >> > > > >> > > It seems to me a real shame that we are disabling this feature of JMS 2.0 >> > > because of the fact that from an AMQP point of view the link *may* be >> > > resumed, but in practice, with JMS, will never be. Would it not be >> > > better >> > > to have a context variable which affects the behaviour of such links to >> > > shared durable subscriptions such that if the context variable returns >> > > "true" the links are removed from the link registry at the time of >> > > connection closure, and if the context value is false, then the current >> > > behaviour is maintained. We could then later add functionality to the >> > > client to specify (via some flag) the behaviour it desires (thus >> > > ultimately >> > > removing the need for the context variable)? >> > > >> > > -- Rob >> > > >> > > >> > > > >> > > > >> > > > >> > > > Thoughts, comments, discuss! >> > > > >> > > > Kind regards, >> > > > Lorenz >> > > > >> > > > >> > > > [1] https://issues.apache.org/jira/browse/QPIDJMS-220 >> > > > >> > I agree that disabling-by-default one of the more useful feature >> > additions seems a real shame. The timing was dissapointing also. >> > >> > The alternative idea for the context variable sounds good to me, as >> > does having the client flag its behaviour in some way. >> > >> > Robbie >> >> Thanks for all the feedback. >> We are looking into options to make this work without leaking Links. >> Depending on how impactful/intrusive the change would have to be we >> might consider including this in v7.0.0 since Rob and Robbie seem to >> feel quite strongly about this. >> >> Regarding the timing, we felt that shipping the broker with a known >> memory leak was undesirable and since this is not a regression but >> a new feature, disabling the new feature by default until a proper >> solution (with a potential change to QPIDJMS-220 and the client) >> could be devised seemed like a reasonable way forward. I am sorry >> that you feel differently. I hope we can come up with a solution >> that is acceptable to everyone. >> >> >> Kind regards, >> Lorenz >> > > Hi, > > I discussed the above with Keith and Alex and we decided that we > are willing to change this in v7.0.0 and spin another RC. > > I attached a patch to QPID-7998 [1] with our proposed change. > Below is a description of the patch. Please indicate whether > you find these changes acceptable so we can respin the RC soon. > > > Longer version: > === > When attaching a new link will always be created for global shared > subscriptions. This is different from before where if it is the same > connection the link would be recovered. But I do not think that this > is observable by a client (other than through dumpLinkRegistry). > > When the subscription is ended (unsubscribe) th
Re: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
On Tue, 2017-11-07 at 09:51 +, Robbie Gemmell wrote: > On 6 November 2017 at 14:42, Lorenz Quack wrote: > > > > On Mon, 2017-11-06 at 11:07 +, Lorenz Quack wrote: > > > > > > On Mon, 2017-11-06 at 10:14 +, Robbie Gemmell wrote: > > > > > > > > > > > > On 3 November 2017 at 16:58, Rob Godfrey > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 1 November 2017 at 10:16, Lorenz Quack > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > We noticed a potential problem with the way JMS 2.0 global shared > > > > > > durable subscriptions are implemented in the JMS client. The > > > > > > implementation was designed, discussed, and implemented in > > > > > > QPIDJMS-220 > > > > > > [1]. > > > > > > > > > > > > When a consumer of a subscription closes the underlying AMQP link is > > > > > > not closed but merely detached since the closing of a subscription > > > > > > link is used as the signal to unsubscribe the subscription. These > > > > > > subscription links remain on the broker until the subscription is > > > > > > unsubscribed (detach with close=true) at which point the broker > > > > > > discards all links associated with the subscription. > > > > > > > > > > > > For non-global subscriptions this does not seem to be a problem > > > > > > since > > > > > > the clientId is used as the container-id and links are reused if > > > > > > possible. > > > > > > > > > > > > For global subscription on the other hand the client uses a random > > > > > > UUID associated with the connection as its own container-id. This > > > > > > means that on every new connection a new link is being estblished > > > > > > rather than recovering an existing one. Over time these > > > > > > subscription > > > > > > links would accumulate on the broker until the subscription is > > > > > > unsubscribed. > > > > > > > > > > > > Since shared durable subscriptions are expected to be long lived > > > > > > this > > > > > > raises some concerns with regards to resource exhaustion on the > > > > > > broker. An application that would spin up a connection do some work > > > > > > on a shared durable global subscription and then disconnect again > > > > > > would be "leaking" links. > > > > > > > > > > > > Due to this concern we plan on disabling shared durable global > > > > > > subscriptions for the initial v7 release of Qpid Broker-J. There > > > > > > will > > > > > > be a context variable to enable the feature. > > > > > > > > > > > > > > > > > It seems to me a real shame that we are disabling this feature of JMS > > > > > 2.0 > > > > > because of the fact that from an AMQP point of view the link *may* be > > > > > resumed, but in practice, with JMS, will never be. Would it not be > > > > > better > > > > > to have a context variable which affects the behaviour of such links > > > > > to > > > > > shared durable subscriptions such that if the context variable returns > > > > > "true" the links are removed from the link registry at the time of > > > > > connection closure, and if the context value is false, then the > > > > > current > > > > > behaviour is maintained. We could then later add functionality to the > > > > > client to specify (via some flag) the behaviour it desires (thus > > > > > ultimately > > > > > removing the need for the context variable)? > > > > > > > > > > -- Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts, comments, discuss! > > > > > > > > > > > > Kind regards, > > > > > > Lorenz > > > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/QPIDJMS-220 > > > > > > > > > > I agree that disabling-by-default one of the more useful feature > > > > additions seems a real shame. The timing was dissapointing also. > > > > > > > > The alternative idea for the context variable sounds good to me, as > > > > does having the client flag its behaviour in some way. > > > > > > > > Robbie > > > Thanks for all the feedback. > > > We are looking into options to make this work without leaking Links. > > > Depending on how impactful/intrusive the change would have to be we > > > might consider including this in v7.0.0 since Rob and Robbie seem to > > > feel quite strongly about this. > > > > > > Regarding the timing, we felt that shipping the broker with a known > > > memory leak was undesirable and since this is not a regression but > > > a new feature, disabling the new feature by default until a proper > > > solution (with a potential change to QPIDJMS-220 and the client) > > > could be devised seemed like a reasonable way forward. I am sorry > > > that you feel differently. I hope we can come up with a solution > > > that is acceptable to everyone. > > > > > > > > > Kind regards, > > > Lorenz > > > > > Hi, > > > > I discussed the above with Keith and Alex and we decided that we > > are willing to change this in v7.0.0 and spin another RC. > >
Re: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
On 7 November 2017 at 10:26, Lorenz Quack wrote: > On Tue, 2017-11-07 at 09:51 +, Robbie Gemmell wrote: > > > > Hi Lorenz, > > > > This sounds/looks good to me overall, though I wonder around whether > > the 'more than 1 left' checking + subsequent calls are racey (e.g > > across different connections with subscribers detaching at the same > > time) and if so about the consequences. > > > > Robbie > > Hi Robbie, > > Well spotted. It is known to be racey. > In the worst case the last two links would unsubscribe concurrently and > both be removed from the link registry. Upon unsubscribe the link would > not be found in the registry and the attach would be rejected with > "not-found". The subscription queue would remain on the broker. > There are other races connected to shared subscriptions / link registry. > That does not make it better but we really want to get the release out > so we created QPID-7996 to address these issues in 7.0.1. > > We are going to back port the change an spin a RC2 today. > > It'd be ugly as hell - but couldn't you just wrap the search for links / link close statement in a synchronized block synchronizing on the vhost or the link registry? -- Rob > Kind regards, > Lorenz > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
[jira] [Created] (QPID-8017) [Broker-J] [BDB] BDB JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
Keith Wall created QPID-8017: Summary: [Broker-J] [BDB] BDB JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger Key: QPID-8017 URL: https://issues.apache.org/jira/browse/QPID-8017 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-broker-7.0.0 Reporter: Keith Wall Reproduction: * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source {{com.sleepycat.je.*}} with Level.ALL * Add a BDB HA VHN/VHN * Expected behaviour: verbose logging from JE. Actual behaviour: moderate logging only For instance, JE writes the following message at {{FINE}} which should be logged by the handler as {{TRACE}} but it is absent. {noformat} 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - [default] Clean file none: predicted min util is below minUtilization, current util min: 20 max: 20, predicted util min: 20 max: 20 {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[ https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8017: - Summary: [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger (was: [Broker-J] [BDB] BDB JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger) > [Broker-J] [BDB] JE log events written at JUL level FINE and below not > included in the log produced by a BrokerLogger > -- > > Key: QPID-8017 > URL: https://issues.apache.org/jira/browse/QPID-8017 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Keith Wall > > Reproduction: > * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source > {{com.sleepycat.je.*}} with Level.ALL > * Add a BDB HA VHN/VHN > * Expected behaviour: verbose logging from JE. Actual behaviour: moderate > logging only > For instance, JE writes the following message at {{FINE}} which should be > logged by the handler as {{TRACE}} but it is absent. > {noformat} > 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - > [default] Clean file none: predicted min util is below minUtilization, > current util min: 20 max: 20, predicted util min: 20 max: 20 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[ https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241819#comment-16241819 ] Keith Wall commented on QPID-8017: -- As described https://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/managelogging.html, I notice that adding the following to the Slf4jLoggingHandler ctor gets the desired functional behaviour. I have not looked at performance implications. {code} java.util.logging.Logger julLogger = java.util.logging.Logger.getLogger("com.sleepycat.je"); julLogger.setLevel(Level.ALL); {code} > [Broker-J] [BDB] JE log events written at JUL level FINE and below not > included in the log produced by a BrokerLogger > -- > > Key: QPID-8017 > URL: https://issues.apache.org/jira/browse/QPID-8017 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Keith Wall > > Reproduction: > * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source > {{com.sleepycat.je.*}} with Level.ALL > * Add a BDB HA VHN/VHN > * Expected behaviour: verbose logging from JE. Actual behaviour: moderate > logging only > For instance, JE writes the following message at {{FINE}} which should be > logged by the handler as {{TRACE}} but it is absent. > {noformat} > 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - > [default] Clean file none: predicted min util is below minUtilization, > current util min: 20 max: 20, predicted util min: 20 max: 20 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[ https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8017: - Affects Version/s: qpid-java-6.1 > [Broker-J] [BDB] JE log events written at JUL level FINE and below not > included in the log produced by a BrokerLogger > -- > > Key: QPID-8017 > URL: https://issues.apache.org/jira/browse/QPID-8017 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0 >Reporter: Keith Wall > > Reproduction: > * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source > {{com.sleepycat.je.*}} with Level.ALL > * Add a BDB HA VHN/VHN > * Expected behaviour: verbose logging from JE. Actual behaviour: moderate > logging only > For instance, JE writes the following message at {{FINE}} which should be > logged by the handler as {{TRACE}} but it is absent. > {noformat} > 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - > [default] Clean file none: predicted min util is below minUtilization, > current util min: 20 max: 20, predicted util min: 20 max: 20 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[ https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8017: - Priority: Minor (was: Major) > [Broker-J] [BDB] JE log events written at JUL level FINE and below not > included in the log produced by a BrokerLogger > -- > > Key: QPID-8017 > URL: https://issues.apache.org/jira/browse/QPID-8017 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0 >Reporter: Keith Wall >Priority: Minor > > Reproduction: > * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source > {{com.sleepycat.je.*}} with Level.ALL > * Add a BDB HA VHN/VHN > * Expected behaviour: verbose logging from JE. Actual behaviour: moderate > logging only > For instance, JE writes the following message at {{FINE}} which should be > logged by the handler as {{TRACE}} but it is absent. > {noformat} > 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) - > [default] Clean file none: predicted min util is below minUtilization, > current util min: 20 max: 20, predicted util min: 20 max: 20 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
On 7 November 2017 at 10:26, Lorenz Quack wrote: > On Tue, 2017-11-07 at 09:51 +, Robbie Gemmell wrote: >> On 6 November 2017 at 14:42, Lorenz Quack wrote: >> > >> > On Mon, 2017-11-06 at 11:07 +, Lorenz Quack wrote: >> > > >> > > On Mon, 2017-11-06 at 10:14 +, Robbie Gemmell wrote: >> > > > >> > > > >> > > > On 3 November 2017 at 16:58, Rob Godfrey >> > > > wrote: >> > > > > >> > > > > >> > > > > >> > > > > On 1 November 2017 at 10:16, Lorenz Quack >> > > > > wrote: >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > We noticed a potential problem with the way JMS 2.0 global shared >> > > > > > durable subscriptions are implemented in the JMS client. The >> > > > > > implementation was designed, discussed, and implemented in >> > > > > > QPIDJMS-220 >> > > > > > [1]. >> > > > > > >> > > > > > When a consumer of a subscription closes the underlying AMQP link >> > > > > > is >> > > > > > not closed but merely detached since the closing of a subscription >> > > > > > link is used as the signal to unsubscribe the subscription. These >> > > > > > subscription links remain on the broker until the subscription is >> > > > > > unsubscribed (detach with close=true) at which point the broker >> > > > > > discards all links associated with the subscription. >> > > > > > >> > > > > > For non-global subscriptions this does not seem to be a problem >> > > > > > since >> > > > > > the clientId is used as the container-id and links are reused if >> > > > > > possible. >> > > > > > >> > > > > > For global subscription on the other hand the client uses a random >> > > > > > UUID associated with the connection as its own container-id. This >> > > > > > means that on every new connection a new link is being estblished >> > > > > > rather than recovering an existing one. Over time these >> > > > > > subscription >> > > > > > links would accumulate on the broker until the subscription is >> > > > > > unsubscribed. >> > > > > > >> > > > > > Since shared durable subscriptions are expected to be long lived >> > > > > > this >> > > > > > raises some concerns with regards to resource exhaustion on the >> > > > > > broker. An application that would spin up a connection do some >> > > > > > work >> > > > > > on a shared durable global subscription and then disconnect again >> > > > > > would be "leaking" links. >> > > > > > >> > > > > > Due to this concern we plan on disabling shared durable global >> > > > > > subscriptions for the initial v7 release of Qpid Broker-J. There >> > > > > > will >> > > > > > be a context variable to enable the feature. >> > > > > > >> > > > > > >> > > > > It seems to me a real shame that we are disabling this feature of >> > > > > JMS 2.0 >> > > > > because of the fact that from an AMQP point of view the link *may* be >> > > > > resumed, but in practice, with JMS, will never be. Would it not be >> > > > > better >> > > > > to have a context variable which affects the behaviour of such links >> > > > > to >> > > > > shared durable subscriptions such that if the context variable >> > > > > returns >> > > > > "true" the links are removed from the link registry at the time of >> > > > > connection closure, and if the context value is false, then the >> > > > > current >> > > > > behaviour is maintained. We could then later add functionality to >> > > > > the >> > > > > client to specify (via some flag) the behaviour it desires (thus >> > > > > ultimately >> > > > > removing the need for the context variable)? >> > > > > >> > > > > -- Rob >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Thoughts, comments, discuss! >> > > > > > >> > > > > > Kind regards, >> > > > > > Lorenz >> > > > > > >> > > > > > >> > > > > > [1] https://issues.apache.org/jira/browse/QPIDJMS-220 >> > > > > > >> > > > I agree that disabling-by-default one of the more useful feature >> > > > additions seems a real shame. The timing was dissapointing also. >> > > > >> > > > The alternative idea for the context variable sounds good to me, as >> > > > does having the client flag its behaviour in some way. >> > > > >> > > > Robbie >> > > Thanks for all the feedback. >> > > We are looking into options to make this work without leaking Links. >> > > Depending on how impactful/intrusive the change would have to be we >> > > might consider including this in v7.0.0 since Rob and Robbie seem to >> > > feel quite strongly about this. >> > > >> > > Regarding the timing, we felt that shipping the broker with a known >> > > memory leak was undesirable and since this is not a regression but >> > > a new feature, disabling the new feature by default until a proper >> > > solution (with a potential change to QPIDJMS-220 and the client) >> > > could be devised seemed like a reasonable way forward. I am sorry >> > > that you feel differently. I hope we can come up with a solution >> > > that is acceptable to everyone. >> > > >> > > >> > > K
Re: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
On Tue, 2017-11-07 at 10:43 +, Rob Godfrey wrote: > On 7 November 2017 at 10:26, Lorenz Quack wrote: > > > > > On Tue, 2017-11-07 at 09:51 +, Robbie Gemmell wrote: > > > > > > > > > Hi Lorenz, > > > > > > This sounds/looks good to me overall, though I wonder around whether > > > the 'more than 1 left' checking + subsequent calls are racey (e.g > > > across different connections with subscribers detaching at the same > > > time) and if so about the consequences. > > > > > > Robbie > > Hi Robbie, > > > > Well spotted. It is known to be racey. > > In the worst case the last two links would unsubscribe concurrently and > > both be removed from the link registry. Upon unsubscribe the link would > > not be found in the registry and the attach would be rejected with > > "not-found". The subscription queue would remain on the broker. > > There are other races connected to shared subscriptions / link registry. > > That does not make it better but we really want to get the release out > > so we created QPID-7996 to address these issues in 7.0.1. > > > > We are going to back port the change an spin a RC2 today. > > > > > It'd be ugly as hell - but couldn't you just wrap the search for links / > link close statement in a synchronized block synchronizing on the vhost or > the link registry? > > -- Rob > I guess. The LinkRegistry is not exposed but I just checked and there does not seem to be anything else that is synchronized on the VirtualHost so we could use that and should not be a lot of contention or potential for deadlocks. Kind regards, Lorenz - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7998) [Broker-J] Disable global shared durable subscriptions by default
[ https://issues.apache.org/jira/browse/QPID-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241859#comment-16241859 ] ASF subversion and git services commented on QPID-7998: --- Commit 0b991f4a9ee462fb7e721df9ebdc683f38ebd858 in qpid-broker-j's branch refs/heads/7.0.x from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0b991f4 ] QPID-7998: [Broker-J][AMQP 1.0] When removing global shared subscription links on detach synchronize on the VirtualHost This is done to avoid a race which would lead to * a client-side 'not-found' error on unsubscribe and * a leaked subscription queue on the broker which might accumulate messages. > [Broker-J] Disable global shared durable subscriptions by default > - > > Key: QPID-7998 > URL: https://issues.apache.org/jira/browse/QPID-7998 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7998-Broker-J-AMQP-1.0-By-default-allow-global-.patch > > > As stated in [1] global shared durable subscriptions can cause an > accumulation of subscription links in link registry. The Broker-J currently > does not have any functionality for automatic removal of old links. Thus, for > v7 the global shared durable subscriptions need to be disabled. If feature is > required, it can be enabled but application would need to unsusbcribe from > shared durable subscriptions periodically or call Virtual Host operation > "purgeLinkRegistry" in order to avoid links accumulation with time. > [1] > https://lists.apache.org/thread.html/729cc17a8b0892d414f456f635ee435e7efeadd14e9123d84e45e3dc@%3Cdev.qpid.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7998) [Broker-J] Disable global shared durable subscriptions by default
[ https://issues.apache.org/jira/browse/QPID-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241858#comment-16241858 ] ASF subversion and git services commented on QPID-7998: --- Commit 3651583a9474a7d7997260897a95ec1432b46956 in qpid-broker-j's branch refs/heads/7.0.x from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3651583 ] QPID-7998: [Broker-J][AMQP 1.0] By default, allow global shared subscriptions but discard their links on detach > [Broker-J] Disable global shared durable subscriptions by default > - > > Key: QPID-7998 > URL: https://issues.apache.org/jira/browse/QPID-7998 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7998-Broker-J-AMQP-1.0-By-default-allow-global-.patch > > > As stated in [1] global shared durable subscriptions can cause an > accumulation of subscription links in link registry. The Broker-J currently > does not have any functionality for automatic removal of old links. Thus, for > v7 the global shared durable subscriptions need to be disabled. If feature is > required, it can be enabled but application would need to unsusbcribe from > shared durable subscriptions periodically or call Virtual Host operation > "purgeLinkRegistry" in order to avoid links accumulation with time. > [1] > https://lists.apache.org/thread.html/729cc17a8b0892d414f456f635ee435e7efeadd14e9123d84e45e3dc@%3Cdev.qpid.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7998) [Broker-J] Allow global shared subscriptions but discard their links on detach
[ https://issues.apache.org/jira/browse/QPID-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7998: - Summary: [Broker-J] Allow global shared subscriptions but discard their links on detach (was: [Broker-J] Disable global shared durable subscriptions by default) > [Broker-J] Allow global shared subscriptions but discard their links on detach > -- > > Key: QPID-7998 > URL: https://issues.apache.org/jira/browse/QPID-7998 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7998-Broker-J-AMQP-1.0-By-default-allow-global-.patch > > > As stated in [1] global shared durable subscriptions can cause an > accumulation of subscription links in link registry. The Broker-J currently > does not have any functionality for automatic removal of old links. Thus, for > v7 the global shared durable subscriptions need to be disabled. If feature is > required, it can be enabled but application would need to unsusbcribe from > shared durable subscriptions periodically or call Virtual Host operation > "purgeLinkRegistry" in order to avoid links accumulation with time. > [1] > https://lists.apache.org/thread.html/729cc17a8b0892d414f456f635ee435e7efeadd14e9123d84e45e3dc@%3Cdev.qpid.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out
Lorenz Quack created QPID-8018: -- Summary: [Java Client, AMQP 0-x] Clarify error message when connection times out Key: QPID-8018 URL: https://issues.apache.org/jira/browse/QPID-8018 Project: Qpid Issue Type: Improvement Components: Java Client Reporter: Lorenz Quack Priority: Minor In certain circumstances the client throws a {{AMQTimeoutException}} with the error message {{"Server did not respond in a timely fashion"}}. This error message is misleading. It is not necessarily the server who did not respond in time. It might be that the client JVM was garbage collecting and did not execute anything which resulted in a timeout, it might be a network issue, and finally it also might be the server not responding in a timely fashion. The error message should be clarified to more clearly express the actual problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
Alex Rudyy created QPID-8019: Summary: [Broker-J][WMC] Change link to broker documentation in web management console Key: QPID-8019 URL: https://issues.apache.org/jira/browse/QPID-8019 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-broker-7.0.0 Reporter: Alex Rudyy Priority: Minor Fix For: qpid-java-broker-7.0.0 The link to broker documentation in WMC points to [http://qpid.apache.org/components/java-broker/] at the moment. After renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename the location of Qpid Broker-J pages on qpid site. The suggested location of broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
[ https://issues.apache.org/jira/browse/QPID-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241942#comment-16241942 ] ASF subversion and git services commented on QPID-8019: --- Commit a09f3797a545ef3a166b0cbeaa902e55ad6e7ef0 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a09f379 ] QPID-8019: [Broker-J][WMC] Change link to broker documentation in web management console > [Broker-J][WMC] Change link to broker documentation in web management console > - > > Key: QPID-8019 > URL: https://issues.apache.org/jira/browse/QPID-8019 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The link to broker documentation in WMC points to > [http://qpid.apache.org/components/java-broker/] at the moment. After > renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename > the location of Qpid Broker-J pages on qpid site. The suggested location of > broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
[ https://issues.apache.org/jira/browse/QPID-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241969#comment-16241969 ] ASF subversion and git services commented on QPID-8019: --- Commit 4e3e558315ecf203b3649c507f1738a42d8f7a5b in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4e3e558 ] QPID-8019: [Broker-J][WMC] Change the value of broker context variable for documentation URL > [Broker-J][WMC] Change link to broker documentation in web management console > - > > Key: QPID-8019 > URL: https://issues.apache.org/jira/browse/QPID-8019 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The link to broker documentation in WMC points to > [http://qpid.apache.org/components/java-broker/] at the moment. After > renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename > the location of Qpid Broker-J pages on qpid site. The suggested location of > broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
[ https://issues.apache.org/jira/browse/QPID-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8019: - Status: Reviewable (was: In Progress) > [Broker-J][WMC] Change link to broker documentation in web management console > - > > Key: QPID-8019 > URL: https://issues.apache.org/jira/browse/QPID-8019 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The link to broker documentation in WMC points to > [http://qpid.apache.org/components/java-broker/] at the moment. After > renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename > the location of Qpid Broker-J pages on qpid site. The suggested location of > broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
[ https://issues.apache.org/jira/browse/QPID-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8019: Assignee: Alex Rudyy > [Broker-J][WMC] Change link to broker documentation in web management console > - > > Key: QPID-8019 > URL: https://issues.apache.org/jira/browse/QPID-8019 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The link to broker documentation in WMC points to > [http://qpid.apache.org/components/java-broker/] at the moment. After > renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename > the location of Qpid Broker-J pages on qpid site. The suggested location of > broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
[ https://issues.apache.org/jira/browse/QPID-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242012#comment-16242012 ] ASF subversion and git services commented on QPID-8019: --- Commit 28b063a912c2c6575db8c4afd7a9e0e4becce1b8 in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=28b063a ] QPID-8019: [Broker-J][WMC] Change link to broker documentation in web management console (cherry picked from commit a09f3797a545ef3a166b0cbeaa902e55ad6e7ef0) > [Broker-J][WMC] Change link to broker documentation in web management console > - > > Key: QPID-8019 > URL: https://issues.apache.org/jira/browse/QPID-8019 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The link to broker documentation in WMC points to > [http://qpid.apache.org/components/java-broker/] at the moment. After > renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename > the location of Qpid Broker-J pages on qpid site. The suggested location of > broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8019) [Broker-J][WMC] Change link to broker documentation in web management console
[ https://issues.apache.org/jira/browse/QPID-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242013#comment-16242013 ] ASF subversion and git services commented on QPID-8019: --- Commit 07198292a8debdc6777bc204af30fd30c547f08b in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0719829 ] QPID-8019: [Broker-J][WMC] Change the value of broker context variable for documentation URL (cherry picked from commit 4e3e558315ecf203b3649c507f1738a42d8f7a5b) > [Broker-J][WMC] Change link to broker documentation in web management console > - > > Key: QPID-8019 > URL: https://issues.apache.org/jira/browse/QPID-8019 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The link to broker documentation in WMC points to > [http://qpid.apache.org/components/java-broker/] at the moment. After > renaming of {{broker for java}} into {{broker-j}}, it makes sense to rename > the location of Qpid Broker-J pages on qpid site. The suggested location of > broker-j pages is [http://qpid.apache.org/components/broker-j/] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7891) AMQConnectionClosedException - Error: Unknown channel id: X [error code 504: channel error]
[ https://issues.apache.org/jira/browse/QPID-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-7891. Resolution: Fixed Closed as duplicate of QPID-7905. > AMQConnectionClosedException - Error: Unknown channel id: X [error code 504: > channel error] > --- > > Key: QPID-7891 > URL: https://issues.apache.org/jira/browse/QPID-7891 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client >Affects Versions: qpid-java-6.1.1 >Reporter: Dharam Thacker >Assignee: Lorenz Quack > Labels: newbie, qpid, qpidclient > Attachments: QpidConfig.java, qpid_debug_logs.txt > > > Hi Team, > I am facing below exception frequently on random time interval for my qpid > client app. I have attached my spring bean definitions as well in attachment > section. > I don't have good way to reproduce this but it happens whenever there is > message burst from queue for consumer application. It's also not a transient > error but it happens quite frequently for us. > URI as per logs : org.apache.qpid.client.AMQConnection > Connection(1):amqp://App41e4abb8a78c4310b5ac40b973f437cc:@App41e4abb8a78c4310b5ac40b973f437cc/b82e317d53cc4f06b2f6cdc347f1a3a5?brokerlist='tcp://broker-2.qpid.services.domain.com:5672' > > *+Note+*: I have attached debug logs as well for details informations > *+Exception Stacktrace:+* > Multiple occurrences for each of below channel ids, > > Unknown channel id: 214 > Unknown channel id: 69 > Unknown channel id: 139 > Unknown channel id: 64 > h2. > > o.s.j.c.CachingConnectionFactory Encountered a JMSException - resetting the > underlying JMS Connection javax.jms.JMSException: Exception thrown against > AMQConnection: Host: broker-2.qpid.services.domain.com Port: 5672 > Virtual Host: 3c6273fa428142108b2fe4ffa4404612 Client ID: > Appbb7488d910fa4c5b8e0561dec8f3f478 Active session count: 11: > org.apache.qpid.AMQConnectionClosedException: Error: Unknown channel id: 139 > [error code 504: channel error]at > org.apache.qpid.client.AMQConnection.convertToJMSException(AMQConnection.java:1550) > at org.apache.qpid.client.AMQConnection.closed(AMQConnection.java:1563) > at > org.apache.qpid.client.AMQProtocolHandler.closed(AMQProtocolHandler.java:235) > at > org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.closed(AMQConnectionDelegate_8_0.java:563) > > at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225) > at java.lang.Thread.run(Thread.java:745) Caused by: > org.apache.qpid.AMQConnectionClosedException: *{color:red}Error: Unknown > channel id: 139{color}* > at > org.apache.qpid.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:90) > > at > org.apache.qpid.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:227) > > at > org.apache.qpid.framing.ConnectionCloseBody.execute(ConnectionCloseBody.java:103) > > at > org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118) > > at > org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:523) > > at > org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:446) > > at > org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:64) > at > org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:473) > > at > org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:549) > > at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:164) > ... 1 common frames omitted > h2. > > o.s.j.c.CachingConnectionFactory Encountered a JMSException - resetting the > underlying JMS Connection javax.jms.JMSException: Exception thrown against > AMQConnection: Host: broker-2.qpid.services.domain.com Port: 5672 > Virtual Host: ad5203dcf2d9445dac4ce7dede1c1723 Client ID: > App95af31d06be944faa6583a2fd7f5bca9 Active session count: 10: > org.apache.qpid.AMQConnectionClosedException: Error: Unknown channel id: 64 > [error code 504: channel error] > at > org.apache.qpid.client.AMQConnection.convertToJMSException(AMQConnection.java:1550) > > at org.apache.qpid.client.AMQConnection.closed(AMQConnection.java:1563) > at > org.apache.qpid.client.AMQProtocolHandler.closed(AMQProtocolHandler.java:235) > > at > org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.closed(AMQConnectionDelegate_8_0.java:563) > > at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225) > > at java.lang.Thread.run(Thread.java:745) Caused by: > org.apache.qpid.AMQConne
[jira] [Updated] (QPID-7885) [Java Broker] Support Java 9
[ https://issues.apache.org/jira/browse/QPID-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7885: - Component/s: (was: Java Client) > [Java Broker] Support Java 9 > > > Key: QPID-7885 > URL: https://issues.apache.org/jira/browse/QPID-7885 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > > With the Java 9 on the horizon it is time to get Qpid's Java components ready. > * make sure component compile with JDK9 > * make sure components run with JRE9 > * take advantage of the new Java Module System -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7726) Upgrade SLF4J to 1.7.25
[ https://issues.apache.org/jira/browse/QPID-7726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7726. -- Resolution: Fixed > Upgrade SLF4J to 1.7.25 > --- > > Key: QPID-7726 > URL: https://issues.apache.org/jira/browse/QPID-7726 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-client-0-x-6.3.0 > > > Upgrade dependency to SLF4j to SLF4J to 1.7.25. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7726) Upgrade SLF4J to 1.7.25
[ https://issues.apache.org/jira/browse/QPID-7726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242087#comment-16242087 ] Keith Wall commented on QPID-7726: -- Was resolved by QPID-7737. > Upgrade SLF4J to 1.7.25 > --- > > Key: QPID-7726 > URL: https://issues.apache.org/jira/browse/QPID-7726 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-client-0-x-6.3.0 > > > Upgrade dependency to SLF4j to SLF4J to 1.7.25. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7256: - Component/s: .NET Client > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: .NET Client, Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7256: - Component/s: (was: .NET Client) > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-100) Check status of broker between tests
Kim van der Riet created QPIDIT-100: --- Summary: Check status of broker between tests Key: QPIDIT-100 URL: https://issues.apache.org/jira/browse/QPIDIT-100 Project: Apache QPID Interoperability Test Suite Issue Type: Improvement Reporter: Kim van der Riet Assignee: Kim van der Riet Fix For: Future If the broker should stop during a test, the test will continue to try to run all of the tests. A check should be made between each test that will ensure the broker is still present. Perhaps a check of the PID will suffice. Note that for some broker configurations (such as multi-node dispatch router tests), multiple nodes and/or brokers may be present, and all of them must be checked. If one or more of the test nodes is missing, the test should immediately terminate with an error message. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-101) Create a configurable timeout option for all tests
Kim van der Riet created QPIDIT-101: --- Summary: Create a configurable timeout option for all tests Key: QPIDIT-101 URL: https://issues.apache.org/jira/browse/QPIDIT-101 Project: Apache QPID Interoperability Test Suite Issue Type: Improvement Affects Versions: Future Reporter: Kim van der Riet Assignee: Kim van der Riet Currently, a hard-wired timeout is used for all tests. However, some tests need more time than others. For example, the large content tests need many minutes per test to complete, but other tests only need several seconds. When these shorter tests fail or get stuck, it is not helpful to wait for a ridiculously long time because one test needs it. It might be helpful to provide each test with a command-line parameter to set the timeout for that test. If not specified on the command-line, each test should provide a reasonable default for that test based on the time required for slower machines. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-101) Create a configurable timeout option for all tests
[ https://issues.apache.org/jira/browse/QPIDIT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-101: Affects Version/s: (was: Future) 0.1.0 Fix Version/s: Future > Create a configurable timeout option for all tests > -- > > Key: QPIDIT-101 > URL: https://issues.apache.org/jira/browse/QPIDIT-101 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: Future > > > Currently, a hard-wired timeout is used for all tests. However, some tests > need more time than others. For example, the large content tests need many > minutes per test to complete, but other tests only need several seconds. > When these shorter tests fail or get stuck, it is not helpful to wait for a > ridiculously long time because one test needs it. > It might be helpful to provide each test with a command-line parameter to set > the timeout for that test. If not specified on the command-line, each test > should provide a reasonable default for that test based on the time required > for slower machines. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242137#comment-16242137 ] Keith Wall commented on QPID-7256: -- I suspect that Steve's observations might have been related to a (direct) memory management problem (QPID-7753 - fixed in Broker-J v7.0). This was worked around in the defect fix releases 6.0.7/6.1.3. If the issue is seen again with one of these brokers, please raise a new JIRA. > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-100) Check status of broker between tests
[ https://issues.apache.org/jira/browse/QPIDIT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-100: Priority: Minor (was: Major) > Check status of broker between tests > > > Key: QPIDIT-100 > URL: https://issues.apache.org/jira/browse/QPIDIT-100 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: Future > > > If the broker should stop during a test, the test will continue to try to run > all of the tests. A check should be made between each test that will ensure > the broker is still present. Perhaps a check of the PID will suffice. > Note that for some broker configurations (such as multi-node dispatch router > tests), multiple nodes and/or brokers may be present, and all of them must be > checked. > If one or more of the test nodes is missing, the test should immediately > terminate with an error message. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-7256. Resolution: Fixed > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-98) Change Proton C++ Receiver shims to use latest non-deprecated API calls
[ https://issues.apache.org/jira/browse/QPIDIT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-98: --- Affects Version/s: (was: 0.1.0) > Change Proton C++ Receiver shims to use latest non-deprecated API calls > --- > > Key: QPIDIT-98 > URL: https://issues.apache.org/jira/browse/QPIDIT-98 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: Proton C++ Shim >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.1.0 > > > After recent updates to the Proton C++, calls to {{proton::value::get<>()}} > are deprecated with warnings. Change the code to use the recommended > {{proton::get<>()}} calls instead. > There is also a possibility that the use of {{proton::default_container}} is > also deprecated, but it is currently not producing a warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-98) Change Proton C++ Receiver shims to use latest non-deprecated API calls
[ https://issues.apache.org/jira/browse/QPIDIT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-98: --- Priority: Minor (was: Major) > Change Proton C++ Receiver shims to use latest non-deprecated API calls > --- > > Key: QPIDIT-98 > URL: https://issues.apache.org/jira/browse/QPIDIT-98 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: Proton C++ Shim >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: 0.1.0 > > > After recent updates to the Proton C++, calls to {{proton::value::get<>()}} > are deprecated with warnings. Change the code to use the recommended > {{proton::get<>()}} calls instead. > There is also a possibility that the use of {{proton::default_container}} is > also deprecated, but it is currently not producing a warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-100) Check status of broker between tests
[ https://issues.apache.org/jira/browse/QPIDIT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-100: Affects Version/s: 0.1.0 > Check status of broker between tests > > > Key: QPIDIT-100 > URL: https://issues.apache.org/jira/browse/QPIDIT-100 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: Future > > > If the broker should stop during a test, the test will continue to try to run > all of the tests. A check should be made between each test that will ensure > the broker is still present. Perhaps a check of the PID will suffice. > Note that for some broker configurations (such as multi-node dispatch router > tests), multiple nodes and/or brokers may be present, and all of them must be > checked. > If one or more of the test nodes is missing, the test should immediately > terminate with an error message. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-99) Install: npm warnings when installing rhea shim to system directory
[ https://issues.apache.org/jira/browse/QPIDIT-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-99: --- Fix Version/s: Future > Install: npm warnings when installing rhea shim to system directory > --- > > Key: QPIDIT-99 > URL: https://issues.apache.org/jira/browse/QPIDIT-99 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Rhea JavaScript Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: Future > > > When installing using cmake to a system directory, at the end of the install > process there is the following npm warning: > {noformat} > npm WARN enoent ENOENT: no such file or directory, open > '/usr/local/libexec/qpid_interop_test/shims/rhea-js/package.json > {noformat} > This does not appear to affect functionality, and the rhea-js shims run > successfully against the other shims. > The error does not appear when installing to a local directory, ie with > CMAKE_INSTALL_PREFIX set to a local directory. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-101) Create a configurable timeout option for all tests
[ https://issues.apache.org/jira/browse/QPIDIT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-101: Priority: Minor (was: Major) > Create a configurable timeout option for all tests > -- > > Key: QPIDIT-101 > URL: https://issues.apache.org/jira/browse/QPIDIT-101 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > Fix For: Future > > > Currently, a hard-wired timeout is used for all tests. However, some tests > need more time than others. For example, the large content tests need many > minutes per test to complete, but other tests only need several seconds. > When these shorter tests fail or get stuck, it is not helpful to wait for a > ridiculously long time because one test needs it. > It might be helpful to provide each test with a command-line parameter to set > the timeout for that test. If not specified on the command-line, each test > should provide a reasonable default for that test based on the time required > for slower machines. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-93) Optionally produce xUnit XML report with test results
[ https://issues.apache.org/jira/browse/QPIDIT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-93: --- Priority: Minor (was: Major) > Optionally produce xUnit XML report with test results > - > > Key: QPIDIT-93 > URL: https://issues.apache.org/jira/browse/QPIDIT-93 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Jiri Daněk >Assignee: Kim van der Riet >Priority: Minor > > Something like the following should do the job. Instead of > https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to > maybe switch from unittest package to py.test, which has xUnit reports built > in. > {noformat} > diff --git a/src/python/qpid_interop_test/jms_messages_test.py > b/src/python/qpid_interop_test/jms_messages_test.py > index 3b54510..3b94f3a 100755 > --- a/src/python/qpid_interop_test/jms_messages_test.py > +++ b/src/python/qpid_interop_test/jms_messages_test.py > @@ -24,19 +24,17 @@ Module to test JMS message types across different APIs > from json import dumps > from os import getenv, path > +import xmlrunner > from proton import symbol > from qpid_interop_test.test_type_map import TestTypeMap > @@ -302,7 +300,7 @@ class TestOptions(object): > Class controlling command-line arguments used to control the test. > """ > def __init__(self, shim_map): > -parser = argparse.ArgumentParser(description='Qpid-interop AMQP > client interoparability test suite ' > +parser = argparse.ArgumentParser(description='Qpid-interop AMQP > client interoperability test suite ' > 'for JMS message types') > parser.add_argument('--sender', action='store', > default='localhost:5672', metavar='IP-ADDR:PORT', > help='Node to which test suite will send > messages.') > @@ -313,6 +311,8 @@ class TestOptions(object): > parser.add_argument('--broker-type', action='store', > metavar='BROKER_NAME', > help='Disable test of broker type (using > connection properties) by specifying the broker' + > ' name, or "None".') > +parser.add_argument('--xunit-report-dir', action='store', > metavar='REPORTS_DIRECTORY', > +help='Generate xUnit report into > REPORTS_DIRECTORY/TEST--.xml') > type_group = parser.add_mutually_exclusive_group() > type_group.add_argument('--include-type', action='append', > metavar='JMS_MESSAGE-TYPE', > help='Name of JMS message type to include. > Supported types:\n%s' % > @@ -421,6 +421,7 @@ if __name__ == '__main__': > TEST_SUITE.addTest(unittest.makeSuite(test_case_class)) > > # Finally, run all the dynamically created tests > -RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE) > +#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE) # type: > unittest.TextTestResult > +RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE) # type: > unittest.TextTestResult > if not RES.wasSuccessful(): > sys.exit(1) > {noformat} > The main "problem" seems that each test has completely separate main method > and builds up options from scratch. Adding this to every test would mean some > unnecessary duplication. So maybe refactor this somewhat at first? On the > other hand, there are good reasons to keep the tests simple... > What do you think? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-98) Change Proton C++ Receiver shims to use latest non-deprecated API calls
[ https://issues.apache.org/jira/browse/QPIDIT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-98: --- Fix Version/s: 0.1.0 > Change Proton C++ Receiver shims to use latest non-deprecated API calls > --- > > Key: QPIDIT-98 > URL: https://issues.apache.org/jira/browse/QPIDIT-98 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: Proton C++ Shim >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.1.0 > > > After recent updates to the Proton C++, calls to {{proton::value::get<>()}} > are deprecated with warnings. Change the code to use the recommended > {{proton::get<>()}} calls instead. > There is also a possibility that the use of {{proton::default_container}} is > also deprecated, but it is currently not producing a warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-98) Change Proton C++ Receiver shims to use latest non-deprecated API calls
[ https://issues.apache.org/jira/browse/QPIDIT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-98. Resolution: Fixed Work completed for 0.1.0 release. > Change Proton C++ Receiver shims to use latest non-deprecated API calls > --- > > Key: QPIDIT-98 > URL: https://issues.apache.org/jira/browse/QPIDIT-98 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: Proton C++ Shim >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > After recent updates to the Proton C++, calls to {{proton::value::get<>()}} > are deprecated with warnings. Change the code to use the recommended > {{proton::get<>()}} calls instead. > There is also a possibility that the use of {{proton::default_container}} is > also deprecated, but it is currently not producing a warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-99) Install: npm warnings when installing rhea shim to system directory
[ https://issues.apache.org/jira/browse/QPIDIT-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-99: --- Fix Version/s: (was: Future) > Install: npm warnings when installing rhea shim to system directory > --- > > Key: QPIDIT-99 > URL: https://issues.apache.org/jira/browse/QPIDIT-99 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Rhea JavaScript Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > When installing using cmake to a system directory, at the end of the install > process there is the following npm warning: > {noformat} > npm WARN enoent ENOENT: no such file or directory, open > '/usr/local/libexec/qpid_interop_test/shims/rhea-js/package.json > {noformat} > This does not appear to affect functionality, and the rhea-js shims run > successfully against the other shims. > The error does not appear when installing to a local directory, ie with > CMAKE_INSTALL_PREFIX set to a local directory. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-89) Detecting failed shims without elapsing full timeout
[ https://issues.apache.org/jira/browse/QPIDIT-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-89: --- Affects Version/s: 0.1.0 > Detecting failed shims without elapsing full timeout > > > Key: QPIDIT-89 > URL: https://issues.apache.org/jira/browse/QPIDIT-89 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Chuck Rolke >Assignee: Kim van der Riet >Priority: Minor > > If a test has a sender that throws but a receiver that does not then the test > may elapse the full timeout period before failing. > What are the rules for a sender throwing an exception so that it is seen by > the test runner? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-97) Release qpid-interop-test 0.1.0
[ https://issues.apache.org/jira/browse/QPIDIT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-97: --- Fix Version/s: 0.1.0 > Release qpid-interop-test 0.1.0 > --- > > Key: QPIDIT-97 > URL: https://issues.apache.org/jira/browse/QPIDIT-97 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.1.0 > > > Release qpid-interop-test version 0.1.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-100) Check status of broker between tests
[ https://issues.apache.org/jira/browse/QPIDIT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-100: Fix Version/s: (was: Future) > Check status of broker between tests > > > Key: QPIDIT-100 > URL: https://issues.apache.org/jira/browse/QPIDIT-100 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > If the broker should stop during a test, the test will continue to try to run > all of the tests. A check should be made between each test that will ensure > the broker is still present. Perhaps a check of the PID will suffice. > Note that for some broker configurations (such as multi-node dispatch router > tests), multiple nodes and/or brokers may be present, and all of them must be > checked. > If one or more of the test nodes is missing, the test should immediately > terminate with an error message. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-101) Create a configurable timeout option for all tests
[ https://issues.apache.org/jira/browse/QPIDIT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-101: Fix Version/s: (was: Future) > Create a configurable timeout option for all tests > -- > > Key: QPIDIT-101 > URL: https://issues.apache.org/jira/browse/QPIDIT-101 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently, a hard-wired timeout is used for all tests. However, some tests > need more time than others. For example, the large content tests need many > minutes per test to complete, but other tests only need several seconds. > When these shorter tests fail or get stuck, it is not helpful to wait for a > ridiculously long time because one test needs it. > It might be helpful to provide each test with a command-line parameter to set > the timeout for that test. If not specified on the command-line, each test > should provide a reasonable default for that test based on the time required > for slower machines. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-86) Inconsistent shim installation
[ https://issues.apache.org/jira/browse/QPIDIT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-86: --- Affects Version/s: 0.1.0 > Inconsistent shim installation > -- > > Key: QPIDIT-86 > URL: https://issues.apache.org/jira/browse/QPIDIT-86 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: Installation >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently the installation is loosely bound together under cmake. However, > the shim installations are not consistent, and use different patterns and > mechanisms. > Change the shim installation so that every shim is under cmake. Cmake may > hand off installation to another installer if necessary. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-6711) [0-8..0-9-1] Client may send a ChannelOpen before connection establishment is complete
[ https://issues.apache.org/jira/browse/QPID-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-6711. Resolution: Cannot Reproduce Cannot reproduce the problem. > [0-8..0-9-1] Client may send a ChannelOpen before connection establishment > is complete > --- > > Key: QPID-6711 > URL: https://issues.apache.org/jira/browse/QPID-6711 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: qpid-java-6.0 > Environment: MacBookAir 1.7 GHz Intel Core i7 > Maximum Memory : 1,908,932,608 bytes > Platform : JVM : Oracle Corporation version: 1.7.0_45-b18 OS : Mac OS X > version: 10.10.4 arch: x86_64 cores: 4 >Reporter: Keith Wall > Attachments: repo.tar.bz2 > > > I am seeing a sporadic issue on the legacy Qpid Client when using the > 0-8..0-91 protocol with SSL. Occasionally, the client is seen to emit a > ChannelOpen before the ConnectionOpenOk has been received. The Java Broker > detects that illegal state and closes the connection. > I have not checked if this is a regression. I am reproducing this issue > running the Perftest profile VaryingNumberOfParticipantsSSL.js using a Java > Broker configured with SSL using the canned test certs. > After augmenting the Broker to log a stack trace > AMQPConnection_0_8#assertState) > {noformat} > 2015-08-26 09:26:47,977 ERROR [IO-/127.0.0.1:51674] > (o.a.q.s.p.v.AMQPConnection_0_8) - Connection is in the wrong state > AWAIT_START_OK , expecting OPEN > java.lang.Exception: null > at > org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.assertState(AMQPConnection_0_8.java:1061) > [classes/:na] > at > org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.receiveChannelOpen(AMQPConnection_0_8.java:1020) > [classes/:na] > at > org.apache.qpid.framing.ChannelOpenBody.process(ChannelOpenBody.java:92) > [classes/:na] > at > org.apache.qpid.codec.ServerDecoder.processMethod(ServerDecoder.java:122) > [classes/:na] > {noformat} > And augmenting the Qpid Client to that IoSender and IoReceiver include the > socket's localport: > {noformat} > 2015-08-26 09:26:47,972 DEBUG [Dispatcher-2-Conn-34] > o.a.q.c.AMQProtocolHandler SEND: AMQP1109 > 2015-08-26 09:26:47,972 INFO [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection > Connection 82 now connected from /127.0.0.1:51674 to localhost/127.0.0.1:5671 > 2015-08-26 09:26:47,973 DEBUG [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection > Are we connected:true > 2015-08-26 09:26:47,973 DEBUG [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection > Connected with ProtocolHandler Version:0-9 > 2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-1] > o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 2, bodyFrame: > [BasicAckBodyImpl: deliveryTag=81, multiple=false] > 2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-34] > o.a.q.c.AMQProtocolHandler SEND: > org.apache.qpid.framing.CompositeAMQDataBlock{ 0=[Frame channelId: 3, > bodyFrame: [BasicPublishBodyImpl: ticket=0, exchange=amq.direct, > routingKey=controllerqueue, mandatory=true, immediate=false]] 1=[Frame > channelId: 3, bodyFrame: ContentHeaderBody{classId=60, weight=0, bodySize=0, > properties=reply-to = null,propertyFlags = 47312,ApplicationID = > null,ClusterID = null,UserId = guest,JMSMessageID = > ID:448e77ea-0fde-3dd8-9133-1654cdb15fad,JMSCorrelationID = > null,JMSDeliveryMode = 2,JMSExpiration = 0,JMSPriority = 4,JMSTimestamp = > 1440577607974,JMSType = null}]} > 2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-34] > o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 2, bodyFrame: > [BasicAckBodyImpl: deliveryTag=1, multiple=false] > 2015-08-26 09:26:47,975 DEBUG [Dispatcher-2-Conn-34] > o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 1, bodyFrame: > [ChannelOpenBody] > 2015-08-26 09:26:47,976 DEBUG [IoRcvr-localhost/127.0.0.1:5671-51674] > o.a.q.c.AMQProtocolHandler RECV: Frame channelId: 0, bodyFrame: > [ConnectionStartBodyImpl: versionMajor=0, versionMinor=9, > serverProperties={product=[LONG_STRING: qpid], version=[LONG_STRING: > 6.0.0-SNAPSHOT], qpid.build=[LONG_STRING: Unversioned directory], > qpid.instance_name=[LONG_STRING: Broker], > qpid.close_when_no_route=[LONG_STRING: true], > qpid.message_compression_supported=[LONG_STRING: true], > qpid.confirmed_publish_supported=[LONG_STRING: true], > qpid.virtualhost_properties_supported=[LONG_STRING: true]}, mechanisms=[80, > 76, 65, 73, 78, 32, 67, 82, 65, 77, 45, 77, 68, 53], locales=[101, 110, 95, > 85, 83]] > 2015-08-26 09:26:47,977 DEBUG [IoRcvr-localhost/127.0.0.1:5671-51674] > o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 0, bodyFrame: > [ConnectionStartOkBodyImpl: clientProperties={instance=[LONG_STRING: > clientid], product=[LONG_STRING: qpid], version=[L
[jira] [Updated] (QPIDIT-81) [C++, python binding] Message priority default test fails, returns 0 not 4
[ https://issues.apache.org/jira/browse/QPIDIT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-81: --- Affects Version/s: 0.1.0 > [C++, python binding] Message priority default test fails, returns 0 not 4 > -- > > Key: QPIDIT-81 > URL: https://issues.apache.org/jira/browse/QPIDIT-81 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton C++ Shim, Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently the Proton C++ and Python bindings do not correctly support AMQP > default values for priority when they are not on the wire, and return a value > of 0. This is causing this part of the message headers and properties test to > fail on these APIs. > This check needs to be disabled until this issue is resolved. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-87) Rhea shims not working with --sender and --receiver options to set TCP address
[ https://issues.apache.org/jira/browse/QPIDIT-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-87: --- Priority: Minor (was: Major) > Rhea shims not working with --sender and --receiver options to set TCP address > -- > > Key: QPIDIT-87 > URL: https://issues.apache.org/jira/browse/QPIDIT-87 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Rhea JavaScript Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > When running a test with the {{sender}} and/or {{receiver}} options (even if > those options are set to the default value), then the shim fails or freezes. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-87) Rhea shims not working with --sender and --receiver options to set TCP address
[ https://issues.apache.org/jira/browse/QPIDIT-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-87: --- Affects Version/s: 0.1.0 > Rhea shims not working with --sender and --receiver options to set TCP address > -- > > Key: QPIDIT-87 > URL: https://issues.apache.org/jira/browse/QPIDIT-87 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Rhea JavaScript Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > When running a test with the {{sender}} and/or {{receiver}} options (even if > those options are set to the default value), then the shim fails or freezes. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-81) [C++, python binding] Message priority default test fails, returns 0 not 4
[ https://issues.apache.org/jira/browse/QPIDIT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-81: --- Priority: Minor (was: Major) > [C++, python binding] Message priority default test fails, returns 0 not 4 > -- > > Key: QPIDIT-81 > URL: https://issues.apache.org/jira/browse/QPIDIT-81 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton C++ Shim, Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently the Proton C++ and Python bindings do not correctly support AMQP > default values for priority when they are not on the wire, and return a value > of 0. This is causing this part of the message headers and properties test to > fail on these APIs. > This check needs to be disabled until this issue is resolved. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5080) Allow Qpid JCA adapter to provide for alternate ConnectionFactory Implementations
[ https://issues.apache.org/jira/browse/QPID-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242167#comment-16242167 ] Keith Wall commented on QPID-5080: -- JCA was removed by QPID-7716, so making this JIRA Won't Fix. > Allow Qpid JCA adapter to provide for alternate ConnectionFactory > Implementations > - > > Key: QPID-5080 > URL: https://issues.apache.org/jira/browse/QPID-5080 > Project: Qpid > Issue Type: Improvement > Components: Java Client, JCA >Affects Versions: 0.22 > Environment: All supported OS platforms, all supported JEE platforms. >Reporter: Weston M. Price >Assignee: Weston M. Price >Priority: Minor > Fix For: Future > > > Currently the Qpid JCA adapter assumes the AMQConnectionFactory is the solve > provider for JMS connectivity. The adapter should be modified to allow for > different CF implementations based on environment etc. > Note, this modification should allow for the outbound and inbound connections > to use a different CF as warranted. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-80) [jms_hdrs_props_test] Using option include-type and a value other than JMS_MESSAGE_TYPE causes failure
[ https://issues.apache.org/jira/browse/QPIDIT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-80: --- Priority: Minor (was: Major) > [jms_hdrs_props_test] Using option include-type and a value other than > JMS_MESSAGE_TYPE causes failure > -- > > Key: QPIDIT-80 > URL: https://issues.apache.org/jira/browse/QPIDIT-80 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: JMS Headers and Properties Test >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > If the option {{--include-type}} is used with a value other than > {{JMS_MESSAGE_TYPE}}, every test fails with > {noformat} > Traceback (most recent call last): > File > "./install/lib/python2.7/site-packages/qpid_interop_test/jms_hdrs_props_test.py", > line 423, in inner_test_method > receive_shim) > File > "./install/lib/python2.7/site-packages/qpid_interop_test/jms_hdrs_props_test.py", > line 246, in run_test > if len(test_values) > 0: > TypeError: object of type 'NoneType' has no len() > {noformat} > This occurs because the test uses only JMS_MESSAGE_TYPE to perform this test, > and using the option excludes this leaving the value map empty. This has been > temporarily fixed by commenting out this option for this test. However, the > intent is that this option will override the default and use the specified > type for the test. Re-enable this option when this has been fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-80) [jms_hdrs_props_test] Using option include-type and a value other than JMS_MESSAGE_TYPE causes failure
[ https://issues.apache.org/jira/browse/QPIDIT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-80: --- Affects Version/s: 0.1.0 > [jms_hdrs_props_test] Using option include-type and a value other than > JMS_MESSAGE_TYPE causes failure > -- > > Key: QPIDIT-80 > URL: https://issues.apache.org/jira/browse/QPIDIT-80 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: JMS Headers and Properties Test >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > If the option {{--include-type}} is used with a value other than > {{JMS_MESSAGE_TYPE}}, every test fails with > {noformat} > Traceback (most recent call last): > File > "./install/lib/python2.7/site-packages/qpid_interop_test/jms_hdrs_props_test.py", > line 423, in inner_test_method > receive_shim) > File > "./install/lib/python2.7/site-packages/qpid_interop_test/jms_hdrs_props_test.py", > line 246, in run_test > if len(test_values) > 0: > TypeError: object of type 'NoneType' has no len() > {noformat} > This occurs because the test uses only JMS_MESSAGE_TYPE to perform this test, > and using the option excludes this leaving the value map empty. This has been > temporarily fixed by commenting out this option for this test. However, the > intent is that this option will override the default and use the specified > type for the test. Re-enable this option when this has been fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-85) Tests don't limit the number of times it tries to connect to a broker
[ https://issues.apache.org/jira/browse/QPIDIT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-85: --- Affects Version/s: 0.1.0 > Tests don't limit the number of times it tries to connect to a broker > - > > Key: QPIDIT-85 > URL: https://issues.apache.org/jira/browse/QPIDIT-85 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > When no broker is present, or when a misconfiguration prevents communication > to the broker, then the test keeps attempting to connect without time or > number limit: > {noformat} > ERROR:root:proton:io: recv: Connection refused > ERROR:root:proton:io: recv: Connection refused > ERROR:root:proton:io: recv: Connection refused > ERROR:root:proton:io: recv: Connection refused > ... > {noformat} > and will keep trying indefinitely, effectively hanging the test. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-3632) Make XAResourceImpl serializable to aid in XA transaction recovery
[ https://issues.apache.org/jira/browse/QPID-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-3632. Resolution: Won't Fix QPID-7716 remove the JCA feature from the client. > Make XAResourceImpl serializable to aid in XA transaction recovery > -- > > Key: QPID-3632 > URL: https://issues.apache.org/jira/browse/QPID-3632 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Affects Versions: 0.10, 0.11, 0.12 > Environment: All platforms. >Reporter: Weston M. Price > Labels: serialization > Fix For: Future > > > A majority of transaction manager serialize an XAResource to a transaction > log in order to be able to automatically recover these resources for in-doubt > transactions. Without this implementing recovery for an XAResource generally > requires vendor specific API's for registration and recovery. > XAResourceImpl should be made serializable to work with a variety of > TransactionManagers without having to resort to vendor specific API's. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5080) Allow Qpid JCA adapter to provide for alternate ConnectionFactory Implementations
[ https://issues.apache.org/jira/browse/QPID-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-5080. -- Resolution: Won't Fix > Allow Qpid JCA adapter to provide for alternate ConnectionFactory > Implementations > - > > Key: QPID-5080 > URL: https://issues.apache.org/jira/browse/QPID-5080 > Project: Qpid > Issue Type: Improvement > Components: Java Client, JCA >Affects Versions: 0.22 > Environment: All supported OS platforms, all supported JEE platforms. >Reporter: Weston M. Price >Assignee: Weston M. Price >Priority: Minor > Fix For: Future > > > Currently the Qpid JCA adapter assumes the AMQConnectionFactory is the solve > provider for JMS connectivity. The adapter should be modified to allow for > different CF implementations based on environment etc. > Note, this modification should allow for the outbound and inbound connections > to use a different CF as warranted. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-102) Add Go client shim for amqp_types-test
Kim van der Riet created QPIDIT-102: --- Summary: Add Go client shim for amqp_types-test Key: QPIDIT-102 URL: https://issues.apache.org/jira/browse/QPIDIT-102 Project: Apache QPID Interoperability Test Suite Issue Type: New Feature Reporter: Kim van der Riet Priority: Minor Add a Go shim for the amqp-types-test. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-3632) Make XAResourceImpl serializable to aid in XA transaction recovery
[ https://issues.apache.org/jira/browse/QPID-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242171#comment-16242171 ] Keith Wall edited comment on QPID-3632 at 11/7/17 3:21 PM: --- QPID-7716 removed the JCA feature from the client. was (Author: k-wall): QPID-7716 remove the JCA feature from the client. > Make XAResourceImpl serializable to aid in XA transaction recovery > -- > > Key: QPID-3632 > URL: https://issues.apache.org/jira/browse/QPID-3632 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Affects Versions: 0.10, 0.11, 0.12 > Environment: All platforms. >Reporter: Weston M. Price > Labels: serialization > Fix For: Future > > > A majority of transaction manager serialize an XAResource to a transaction > log in order to be able to automatically recover these resources for in-doubt > transactions. Without this implementing recovery for an XAResource generally > requires vendor specific API's for registration and recovery. > XAResourceImpl should be made serializable to work with a variety of > TransactionManagers without having to resort to vendor specific API's. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-79) Stopping Python tests using ctrl+c sometimes results in a zombie shim
[ https://issues.apache.org/jira/browse/QPIDIT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-79: --- Affects Version/s: 0.1.0 > Stopping Python tests using ctrl+c sometimes results in a zombie shim > - > > Key: QPIDIT-79 > URL: https://issues.apache.org/jira/browse/QPIDIT-79 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Labels: gotcha > > When interrupting some tests (particularly Python tests) using ctrl+c will > stop the test, but will sometimes leave a zombie process behind (either a > Sender or a Receiver process). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-102) Add Go client shim for amqp_types-test
[ https://issues.apache.org/jira/browse/QPIDIT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-102. --- Resolution: Duplicate Dup of QPIDIT-76 > Add Go client shim for amqp_types-test > -- > > Key: QPIDIT-102 > URL: https://issues.apache.org/jira/browse/QPIDIT-102 > Project: Apache QPID Interoperability Test Suite > Issue Type: New Feature >Reporter: Kim van der Riet >Priority: Minor > > Add a Go shim for the amqp-types-test. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-97) Release qpid-interop-test 0.1.0
[ https://issues.apache.org/jira/browse/QPIDIT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-97: --- Affects Version/s: (was: 0.1.0) > Release qpid-interop-test 0.1.0 > --- > > Key: QPIDIT-97 > URL: https://issues.apache.org/jira/browse/QPIDIT-97 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.1.0 > > > Release qpid-interop-test version 0.1.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-74) Add command-line switch to enable SASL
[ https://issues.apache.org/jira/browse/QPIDIT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-74: --- Priority: Minor (was: Major) > Add command-line switch to enable SASL > -- > > Key: QPIDIT-74 > URL: https://issues.apache.org/jira/browse/QPIDIT-74 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently, SASL is not used for tests. Create a switch to enable SASL and/or > control its mechanisms. This will entail adding this to the broker_properties > module, as well as to all shims. The SASL details will need to be sent to the > shim in JSON format. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-3693) Implement ConnectionConsumer for ASF integration
[ https://issues.apache.org/jira/browse/QPID-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-3693. Resolution: Won't Fix JCA was removed by QPID-7716, so making this JIRA Won't Fix. > Implement ConnectionConsumer for ASF integration > > > Key: QPID-3693 > URL: https://issues.apache.org/jira/browse/QPID-3693 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Affects Versions: 0.12 > Environment: All platforms, JMS client. >Reporter: Weston M. Price >Assignee: Weston M. Price >Priority: Minor > Labels: jms-compliance > Fix For: Future > > > As per the JMS spec, section 8, the JMS spec allows for ASF integration via > the use of the ConnectionConsumer/ServerSessionPool/ServerSesssion. Currently > the JMS client doesn't not provide a ConnectionConsumer. For concurrent > processing of messages, better resource usage and overall throughput, it > would be beneficial if the JMS client implemented the ConnectionConsumer that > could then be used for better ASF integration. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDIT-68) Amqp Types test for binary sends only printable strings
[ https://issues.apache.org/jira/browse/QPIDIT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned QPIDIT-68: -- Assignee: Kim van der Riet > Amqp Types test for binary sends only printable strings > --- > > Key: QPIDIT-68 > URL: https://issues.apache.org/jira/browse/QPIDIT-68 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test >Affects Versions: 0.1.0 >Reporter: Chuck Rolke >Assignee: Kim van der Riet > > In the Amqp Types test the binary data is defined in Json. One of the defs is > huge but the first four are defined as: > {noformat} > 'binary': [bytes(), >bytes(12345), >b'Hello, world', >b'\\x01\\x02\\x03\\x04\\x05abcde\\x80\\x81\\xfe\\xff', > {noformat} > Adding a little code to instrument the cli argument containing the Json and > running a wireshark snoop reveals how these four strings are handled by > ProtonCpp. > Note that jira makes it hard to render a backslash character. In these tables > the token represents on ascii character. > h3. Json command line arg > The json generated by python arrives at ProtonCpp arg four as a string > ||position||character||hex|| > |0|'['|0x5b| > |1|'"'|0x22| > |2|'"'|0x22| > |3|','|0x2c| > |4|' '|0x20| > |5|'"'|0x22| > |6|'1'|0x31| > |7|'2'|0x32| > |8|'3'|0x33| > |9|'4'|0x34| > |10|'5'|0x35| > |11|'"'|0x22| > |12|','|0x2c| > |13|' '|0x20| > |14|'"'|0x22| > |15|'H'|0x48| > |16|'e'|0x65| > |17|'l'|0x6c| > |18|'l'|0x6c| > |19|'o'|0x6f| > |20|','|0x2c| > |21|' '|0x20| > |22|'w'|0x77| > |23|'o'|0x6f| > |24|'r'|0x72| > |25|'l'|0x6c| > |26|'d'|0x64| > |27|'"'|0x22| > |28|','|0x2c| > |29|' '|0x20| > |30|'"'|0x22| > |31|'backslash'|0x5c| > |32|'backslash'|0x5c| > |33|'x'|0x78| > |34|'0'|0x30| > |35|'1'|0x31| > |36|'backslash'|0x5c| > |37|'backslash'|0x5c| > |38|'x'|0x78| > |39|'0'|0x30| > |40|'2'|0x32| > |41|'backslash'|0x5c| > |42|'backslash'|0x5c| > |43|'x'|0x78| > |44|'0'|0x30| > |45|'3'|0x33| > |46|'backslash'|0x5c| > |47|'backslash'|0x5c| > |48|'x'|0x78| > |49|'0'|0x30| > |50|'4'|0x34| > |51|'backslash'|0x5c| > |52|'backslash'|0x5c| > |53|'x'|0x78| > |54|'0'|0x30| > |55|'5'|0x35| > |56|'a'|0x61| > |57|'b'|0x62| > |58|'c'|0x63| > |59|'d'|0x64| > |60|'e'|0x65| > |61|'backslash'|0x5c| > |62|'backslash'|0x5c| > |63|'x'|0x78| > |64|'8'|0x38| > |65|'0'|0x30| > |66|'backslash'|0x5c| > |67|'backslash'|0x5c| > |68|'x'|0x78| > |69|'8'|0x38| > |70|'1'|0x31| > |71|'backslash'|0x5c| > |72|'backslash'|0x5c| > |73|'x'|0x78| > |74|'f'|0x66| > |75|'e'|0x65| > |76|'backslash'|0x5c| > |77|'backslash'|0x5c| > |78|'x'|0x78| > |79|'f'|0x66| > |80|'f'|0x66| > |81|'"'|0x22| > |82|','|0x2c| > h3. Over the wire > The ProtonCpp does its work and sends messages over the wire. > * The messages are encoded with type A0 (binary:vbin8) and an appropriate > length. > ||Message||Content|| > | 0 | "" | > | 1 | "12345" | > | 2 | "Hello, world" | > | 3 | "x01x02x03x05x05 > abcd x80x81xfexff| > The intent of the test appears to have binary, non-printable bytes (0x01, > 0x02, 0xff) in the messages but that's not what happens. > Maybe this is something simple like having the double backslashes in the test > python code. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-3702) Qpid JCA Adapter should implement javax.jms.ServerSessionPool and javax.jms.ServerSession for ASF
[ https://issues.apache.org/jira/browse/QPID-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-3702. Resolution: Won't Fix JCA was removed by QPID-7716, so making this JIRA Won't Fix. > Qpid JCA Adapter should implement javax.jms.ServerSessionPool and > javax.jms.ServerSession for ASF > - > > Key: QPID-3702 > URL: https://issues.apache.org/jira/browse/QPID-3702 > Project: Qpid > Issue Type: Sub-task > Components: JCA >Affects Versions: 0.15 > Environment: All OS platforms, all supported Qpid JCA Application > Server Platforms >Reporter: Weston M. Price >Assignee: Weston M. Price > Fix For: Future > > > As a sub-task of QPID-3693, the JCA adapter should implement the > ServerSessionPool and ServerSession interfaces for better JEE/ASF > integration. Both interfaces are required for the ConnectionConsumer to > function properly. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-68) Amqp Types test for binary sends only printable strings
[ https://issues.apache.org/jira/browse/QPIDIT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-68: --- Affects Version/s: 0.1.0 > Amqp Types test for binary sends only printable strings > --- > > Key: QPIDIT-68 > URL: https://issues.apache.org/jira/browse/QPIDIT-68 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test >Affects Versions: 0.1.0 >Reporter: Chuck Rolke > > In the Amqp Types test the binary data is defined in Json. One of the defs is > huge but the first four are defined as: > {noformat} > 'binary': [bytes(), >bytes(12345), >b'Hello, world', >b'\\x01\\x02\\x03\\x04\\x05abcde\\x80\\x81\\xfe\\xff', > {noformat} > Adding a little code to instrument the cli argument containing the Json and > running a wireshark snoop reveals how these four strings are handled by > ProtonCpp. > Note that jira makes it hard to render a backslash character. In these tables > the token represents on ascii character. > h3. Json command line arg > The json generated by python arrives at ProtonCpp arg four as a string > ||position||character||hex|| > |0|'['|0x5b| > |1|'"'|0x22| > |2|'"'|0x22| > |3|','|0x2c| > |4|' '|0x20| > |5|'"'|0x22| > |6|'1'|0x31| > |7|'2'|0x32| > |8|'3'|0x33| > |9|'4'|0x34| > |10|'5'|0x35| > |11|'"'|0x22| > |12|','|0x2c| > |13|' '|0x20| > |14|'"'|0x22| > |15|'H'|0x48| > |16|'e'|0x65| > |17|'l'|0x6c| > |18|'l'|0x6c| > |19|'o'|0x6f| > |20|','|0x2c| > |21|' '|0x20| > |22|'w'|0x77| > |23|'o'|0x6f| > |24|'r'|0x72| > |25|'l'|0x6c| > |26|'d'|0x64| > |27|'"'|0x22| > |28|','|0x2c| > |29|' '|0x20| > |30|'"'|0x22| > |31|'backslash'|0x5c| > |32|'backslash'|0x5c| > |33|'x'|0x78| > |34|'0'|0x30| > |35|'1'|0x31| > |36|'backslash'|0x5c| > |37|'backslash'|0x5c| > |38|'x'|0x78| > |39|'0'|0x30| > |40|'2'|0x32| > |41|'backslash'|0x5c| > |42|'backslash'|0x5c| > |43|'x'|0x78| > |44|'0'|0x30| > |45|'3'|0x33| > |46|'backslash'|0x5c| > |47|'backslash'|0x5c| > |48|'x'|0x78| > |49|'0'|0x30| > |50|'4'|0x34| > |51|'backslash'|0x5c| > |52|'backslash'|0x5c| > |53|'x'|0x78| > |54|'0'|0x30| > |55|'5'|0x35| > |56|'a'|0x61| > |57|'b'|0x62| > |58|'c'|0x63| > |59|'d'|0x64| > |60|'e'|0x65| > |61|'backslash'|0x5c| > |62|'backslash'|0x5c| > |63|'x'|0x78| > |64|'8'|0x38| > |65|'0'|0x30| > |66|'backslash'|0x5c| > |67|'backslash'|0x5c| > |68|'x'|0x78| > |69|'8'|0x38| > |70|'1'|0x31| > |71|'backslash'|0x5c| > |72|'backslash'|0x5c| > |73|'x'|0x78| > |74|'f'|0x66| > |75|'e'|0x65| > |76|'backslash'|0x5c| > |77|'backslash'|0x5c| > |78|'x'|0x78| > |79|'f'|0x66| > |80|'f'|0x66| > |81|'"'|0x22| > |82|','|0x2c| > h3. Over the wire > The ProtonCpp does its work and sends messages over the wire. > * The messages are encoded with type A0 (binary:vbin8) and an appropriate > length. > ||Message||Content|| > | 0 | "" | > | 1 | "12345" | > | 2 | "Hello, world" | > | 3 | "x01x02x03x05x05 > abcd x80x81xfexff| > The intent of the test appears to have binary, non-printable bytes (0x01, > 0x02, 0xff) in the messages but that's not what happens. > Maybe this is something simple like having the double backslashes in the test > python code. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-64) Add command-line controls for AMQP_large_content_test to control size
[ https://issues.apache.org/jira/browse/QPIDIT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-64: --- Priority: Minor (was: Major) > Add command-line controls for AMQP_large_content_test to control size > - > > Key: QPIDIT-64 > URL: https://issues.apache.org/jira/browse/QPIDIT-64 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: AMQP Large Content Test >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Add a command-line parameter to control the inclusion/exclusion of the size > of the messages to be tested in MBytes. Currently, the test uses 1, 10, 100 > (MBytes) for testing and is fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-65) Add command-line controls to JMS_hdrs_props_test to control test more precisely
[ https://issues.apache.org/jira/browse/QPIDIT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-65: --- Priority: Minor (was: Major) > Add command-line controls to JMS_hdrs_props_test to control test more > precisely > --- > > Key: QPIDIT-65 > URL: https://issues.apache.org/jira/browse/QPIDIT-65 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Components: JMS Headers and Properties Test >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The JMS hdrs_props_test needs additional command-line parameters to control > the test precisely. Since the test by default uses only the JMS_MESSAGE_TYPE > for this test, the --{include, exclude}-type paramter has no effect at > present, but should be used to change/modify the base message type. In > addition, a parameter switching on/off the headers and parameters is needed, > also a control for the type of header and type of parameters used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-63) Accomodate AMQP.Net Lite test broker
[ https://issues.apache.org/jira/browse/QPIDIT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-63: --- Priority: Minor (was: Major) > Accomodate AMQP.Net Lite test broker > > > Key: QPIDIT-63 > URL: https://issues.apache.org/jira/browse/QPIDIT-63 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement > Environment: .NET Core or Mono to compile/run broker >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Minor > > [AMQP.Net Lite|https://github.com/Azure/amqpnetlite] includes a sub project > _TestAmqpBroker_ used originally as a target for self tests. This broker is > not intended to be used as an enterprise grade product but it functions > perfectly well as a target for QPIDIT tests. In fact it already passes most > of the AMQP Types tests. > This issue tracks adjustments to the QPIDIT test suite required for the Lite > test broker. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-58) Add auto-detection of shims
[ https://issues.apache.org/jira/browse/QPIDIT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-58: --- Issue Type: Improvement (was: Task) > Add auto-detection of shims > --- > > Key: QPIDIT-58 > URL: https://issues.apache.org/jira/browse/QPIDIT-58 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently the shims are included by hard-coding paths into the test files. A > small change in directory structure will enable the shims to be auto-detected > at run-time and included if present. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-61) Condense common code from the Python tests into a test module.
[ https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-61: --- Priority: Minor (was: Major) > Condense common code from the Python tests into a test module. > -- > > Key: QPIDIT-61 > URL: https://issues.apache.org/jira/browse/QPIDIT-61 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: AMQP Large Content Test, AMQP Types Test, JMS Headers > and Properties Test, JMS Message Test >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Each test was written independently of the others. While this is a quick way > to start, it has not lead to a lot of duplicated code and common patterns. It > would help maintenance and readability of the code if the common bits were > placed into a test library. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-58) Add auto-detection of shims
[ https://issues.apache.org/jira/browse/QPIDIT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-58: --- Priority: Minor (was: Major) > Add auto-detection of shims > --- > > Key: QPIDIT-58 > URL: https://issues.apache.org/jira/browse/QPIDIT-58 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Currently the shims are included by hard-coding paths into the test files. A > small change in directory structure will enable the shims to be auto-detected > at run-time and included if present. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-54) Align project directory structure with install directory structure
[ https://issues.apache.org/jira/browse/QPIDIT-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-54: --- Affects Version/s: 0.1.0 > Align project directory structure with install directory structure > -- > > Key: QPIDIT-54 > URL: https://issues.apache.org/jira/browse/QPIDIT-54 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The installed test uses a different directory structure to that used in the > checked-out environment. This makes it difficult to run the tests uniformly > from both environments. > By changing the checked-out directory structure to match that in the > installed location, the installation process itself would be a lot simpler; > also it would be easy to run the tests in both locations without messing with > source code (to change the shim paths). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-54) Align project directory structure with install directory structure
[ https://issues.apache.org/jira/browse/QPIDIT-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-54: --- Priority: Minor (was: Major) > Align project directory structure with install directory structure > -- > > Key: QPIDIT-54 > URL: https://issues.apache.org/jira/browse/QPIDIT-54 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The installed test uses a different directory structure to that used in the > checked-out environment. This makes it difficult to run the tests uniformly > from both environments. > By changing the checked-out directory structure to match that in the > installed location, the installation process itself would be a lot simpler; > also it would be easy to run the tests in both locations without messing with > source code (to change the shim paths). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-46) Correctly encode AMQP types within complex types list and map
[ https://issues.apache.org/jira/browse/QPIDIT-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-46: --- Affects Version/s: 0.1.0 > Correctly encode AMQP types within complex types list and map > - > > Key: QPIDIT-46 > URL: https://issues.apache.org/jira/browse/QPIDIT-46 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test, Proton C++ Shim, Proton Python Shim, > Rhea JavaScript Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Currently the AMQP type tests for list and map are using only strings. An > extra step for encoding/decoding these on the Sender/Receiver shims are > needed. At present, the list and map keys and elements are created using a > string format {{"type:value"}}, but these are simply being used as-is as > string literals. > Currently all shim tests for these types pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDIT-45) Add AMQP distributed transactions test
[ https://issues.apache.org/jira/browse/QPIDIT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet closed QPIDIT-45. -- Resolution: Won't Fix The AMQP 1.0 specification does not yet specify how distributed transactions will be conducted on AMQP 1.0 brokers. Until this is done, this task cannot be completed. > Add AMQP distributed transactions test > -- > > Key: QPIDIT-45 > URL: https://issues.apache.org/jira/browse/QPIDIT-45 > Project: Apache QPID Interoperability Test Suite > Issue Type: New Feature > Components: AMQP Distributed Transactions Test >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Add a test for AMQP distributed transactions between AMQP clients -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDIT-44) Add AMQP large content test
[ https://issues.apache.org/jira/browse/QPIDIT-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved QPIDIT-44. Resolution: Fixed This test is complete for C++, Python and .NetLite. There is a separate issue regarding how slow these tests run on the brokers. > Add AMQP large content test > --- > > Key: QPIDIT-44 > URL: https://issues.apache.org/jira/browse/QPIDIT-44 > Project: Apache QPID Interoperability Test Suite > Issue Type: New Feature > Components: AMQP Large Content Test >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Add a test for large message content in AMQP messages. The large content > needs to be in both the message body (for types that have variable size > capabilities) and applicable message headers and properties. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7948) [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to topic within no subscribers
[ https://issues.apache.org/jira/browse/QPID-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7948: - Component/s: (was: Java Client) > [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to > topic within no subscribers > -- > > Key: QPID-7948 > URL: https://issues.apache.org/jira/browse/QPID-7948 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > Testing on master today, If publish confirms is enabled, if I sent to a topic > with no subscribers, the client hangs in the following way: > {noformat} > javax.jms.JMSException: Server did not respond in a timely fashion > at > org.apache.qpid.client.BasicMessageProducer_0_8.sendMessage(BasicMessageProducer_0_8.java:386) > at > org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:549) > at > org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:333) > at > org.apache.qpid.server.security.acl.MessagingACLTest.testPublishToTempTopicSuccess(MessagingACLTest.java:483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:181) > at junit.framework.TestCase.runBare(TestCase.java:141) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:91) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:165) > at junit.framework.TestSuite.runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(TestSuite.java:250) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {noformat} > Currently, the Broker does not send a nack in this case, but the client > awaits all the same. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7948) [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to topic within no subscribers
[ https://issues.apache.org/jira/browse/QPID-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242204#comment-16242204 ] Keith Wall commented on QPID-7948: -- The RabbitMQ specification https://www.rabbitmq.com/confirms.html say: bq. After a channel is put into confirm mode, all subsequently published messages will be confirmed or nack'd once. No guarantees are made as to how soon a message is confirmed. No message will be both confirmed and nicked. so I think the defect is in the Broker, rather than Client. > [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to > topic within no subscribers > -- > > Key: QPID-7948 > URL: https://issues.apache.org/jira/browse/QPID-7948 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > Testing on master today, If publish confirms is enabled, if I sent to a topic > with no subscribers, the client hangs in the following way: > {noformat} > javax.jms.JMSException: Server did not respond in a timely fashion > at > org.apache.qpid.client.BasicMessageProducer_0_8.sendMessage(BasicMessageProducer_0_8.java:386) > at > org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:549) > at > org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:333) > at > org.apache.qpid.server.security.acl.MessagingACLTest.testPublishToTempTopicSuccess(MessagingACLTest.java:483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:181) > at junit.framework.TestCase.runBare(TestCase.java:141) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:91) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:165) > at junit.framework.TestSuite.runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(TestSuite.java:250) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > {noformat} > Currently, the Broker does not send a nack in this case, but the client > awaits all the same. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-37) Add test timeout to receiver shims so that when not all expected messages are received, the test does not wait indefinitely
[ https://issues.apache.org/jira/browse/QPIDIT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-37: --- Priority: Minor (was: Major) > Add test timeout to receiver shims so that when not all expected messages are > received, the test does not wait indefinitely > --- > > Key: QPIDIT-37 > URL: https://issues.apache.org/jira/browse/QPIDIT-37 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Proton C++ Shim, Proton Python Shim, Qpid Jms Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Sometimes the broker fails or does not deliver the expected number of > messages. Currently the shims wait indefinitely for the messages, and this > causes the test to effectively hang instead of failing and allowing the > following test to run. > Add a timeout to the tests so that the test will fail gracefully if not all > messages are received within a reasonable time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-37) Add test timeout to receiver shims so that when not all expected messages are received, the test does not wait indefinitely
[ https://issues.apache.org/jira/browse/QPIDIT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-37: --- Affects Version/s: 0.1.0 > Add test timeout to receiver shims so that when not all expected messages are > received, the test does not wait indefinitely > --- > > Key: QPIDIT-37 > URL: https://issues.apache.org/jira/browse/QPIDIT-37 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Proton C++ Shim, Proton Python Shim, Qpid Jms Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Sometimes the broker fails or does not deliver the expected number of > messages. Currently the shims wait indefinitely for the messages, and this > causes the test to effectively hang instead of failing and allowing the > following test to run. > Add a timeout to the tests so that the test will fail gracefully if not all > messages are received within a reasonable time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-14) ProtonPython shims hang (wait indefinitely) when no broker exists
[ https://issues.apache.org/jira/browse/QPIDIT-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-14: --- Priority: Minor (was: Major) > ProtonPython shims hang (wait indefinitely) when no broker exists > - > > Key: QPIDIT-14 > URL: https://issues.apache.org/jira/browse/QPIDIT-14 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > If the test is started without a running broker, the ProtonPython shim > appears to hang. The test should include a timeout for connectivity to the > broker, and fail with an appropriate message. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-14) ProtonPython shims hang (wait indefinitely) when no broker exists
[ https://issues.apache.org/jira/browse/QPIDIT-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-14: --- Affects Version/s: 0.1.0 > ProtonPython shims hang (wait indefinitely) when no broker exists > - > > Key: QPIDIT-14 > URL: https://issues.apache.org/jira/browse/QPIDIT-14 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > If the test is started without a running broker, the ProtonPython shim > appears to hang. The test should include a timeout for connectivity to the > broker, and fail with an appropriate message. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-23) [Python binding] Float type fails on RHEL7
[ https://issues.apache.org/jira/browse/QPIDIT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-23: --- Affects Version/s: 0.1.0 > [Python binding] Float type fails on RHEL7 > -- > > Key: QPIDIT-23 > URL: https://issues.apache.org/jira/browse/QPIDIT-23 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > When running on RHEL7, float type tests fail with "OverflowError: in method > 'pn_put_float', argument 2 of type 'float'". Works ok on Fedora 22. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-12) Implement AMQP type array for QpidJms shim
[ https://issues.apache.org/jira/browse/QPIDIT-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-12: --- Priority: Minor (was: Major) > Implement AMQP type array for QpidJms shim > -- > > Key: QPIDIT-12 > URL: https://issues.apache.org/jira/browse/QPIDIT-12 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Qpid Jms Shim >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type array has not been implemented in the QpidJms shim. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7835) dead lock error
[ https://issues.apache.org/jira/browse/QPID-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-7835. Resolution: Cannot Reproduce > dead lock error > --- > > Key: QPID-7835 > URL: https://issues.apache.org/jira/browse/QPID-7835 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24 >Reporter: hanfeng > Attachments: jstack.txt > > > When the message server links over time, a message is sent, the caller to > perceive the message send timeout, take the initiative to close the session, > at the same time links are perceived to request timeout to shut down > connection, re link the message server. > When the link function of doClose to get off the lock _failoverMutex, but did > not get a specific lock _messageDeliveryLock to close the session, close the > session function close to get to the _messageDeliveryLock _failoverMutex > lock, lock wait for link > Deadlock. > Modification method. > In session's close function, add a judgment that you are closing session. > public void close(long timeout) throws JMSException > { > {color:red} if (super.isClosing()) return ;{color} > setClosing(true); > lockMessageDelivery(); > try > { > // We must close down all producers and consumers in an orderly > fashion. This is the only method > // that can be called from a different thread of control from the > one controlling the session. > synchronized (getFailoverMutex()) > { > close(timeout, true); > } > } > finally > { > unlockMessageDelivery(); > } > } -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-10) AMQP type double and float fails in QpidJms -> QpidJms test
[ https://issues.apache.org/jira/browse/QPIDIT-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-10: --- Affects Version/s: 0.1.0 > AMQP type double and float fails in QpidJms -> QpidJms test > --- > > Key: QPIDIT-10 > URL: https://issues.apache.org/jira/browse/QPIDIT-10 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test, Qpid Jms Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Both AMQP type double and float fail when run from QpidJms to QpidJms with > the following error: > {noformat} > AssertionError: > sent:['0x', '0x8000', '0x40490fdb', '0xc02df854', > '0x0001', '0x8001', '0x007f', '0x807f', '0x0080', > '0x8080', '0x7f7f', '0xff7f', '0x7f80', '0xff80', > '0x7fc0', '0xffc0'] > received:['0x', '0x8000', '0x40490fdb', '0xc02df854', > '0x0001', '0x8001', '0x007f', '0x807f', '0x0080', > '0x8080', '0x7f7f', '0xff7f', '0x7f80', '0xff80', > '0x7fc0', '0x7fc0'] > {noformat} > (Similar for AMQP type double) > The underlying issue is that the IEEE encoding for -NaN is not supported in > Java, or is not being correctly expressed. The test sends value > {{0xffc0}} (-NaN), but this is being returned as {{0x7fc0}} (+NaN), > causing the test to fail. > If this is in fact caused by Java's implementation of {{float}} and > {{double}}, then this should not be considered a hard failure, but rather an > expected failure which is ignored and does not cause the overall test to > fail. Provision for this type of case should be made in the test framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7835) dead lock error
[ https://issues.apache.org/jira/browse/QPID-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242242#comment-16242242 ] Keith Wall commented on QPID-7835: -- Several dead locking defects were fixed between 0.24 and current releases. Closing as not reproducible. > dead lock error > --- > > Key: QPID-7835 > URL: https://issues.apache.org/jira/browse/QPID-7835 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24 >Reporter: hanfeng > Attachments: jstack.txt > > > When the message server links over time, a message is sent, the caller to > perceive the message send timeout, take the initiative to close the session, > at the same time links are perceived to request timeout to shut down > connection, re link the message server. > When the link function of doClose to get off the lock _failoverMutex, but did > not get a specific lock _messageDeliveryLock to close the session, close the > session function close to get to the _messageDeliveryLock _failoverMutex > lock, lock wait for link > Deadlock. > Modification method. > In session's close function, add a judgment that you are closing session. > public void close(long timeout) throws JMSException > { > {color:red} if (super.isClosing()) return ;{color} > setClosing(true); > lockMessageDelivery(); > try > { > // We must close down all producers and consumers in an orderly > fashion. This is the only method > // that can be called from a different thread of control from the > one controlling the session. > synchronized (getFailoverMutex()) > { > close(timeout, true); > } > } > finally > { > unlockMessageDelivery(); > } > } -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-10) AMQP type double and float fails in QpidJms -> QpidJms test
[ https://issues.apache.org/jira/browse/QPIDIT-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-10: --- Priority: Minor (was: Major) > AMQP type double and float fails in QpidJms -> QpidJms test > --- > > Key: QPIDIT-10 > URL: https://issues.apache.org/jira/browse/QPIDIT-10 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: AMQP Types Test, Qpid Jms Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > Both AMQP type double and float fail when run from QpidJms to QpidJms with > the following error: > {noformat} > AssertionError: > sent:['0x', '0x8000', '0x40490fdb', '0xc02df854', > '0x0001', '0x8001', '0x007f', '0x807f', '0x0080', > '0x8080', '0x7f7f', '0xff7f', '0x7f80', '0xff80', > '0x7fc0', '0xffc0'] > received:['0x', '0x8000', '0x40490fdb', '0xc02df854', > '0x0001', '0x8001', '0x007f', '0x807f', '0x0080', > '0x8080', '0x7f7f', '0xff7f', '0x7f80', '0xff80', > '0x7fc0', '0x7fc0'] > {noformat} > (Similar for AMQP type double) > The underlying issue is that the IEEE encoding for -NaN is not supported in > Java, or is not being correctly expressed. The test sends value > {{0xffc0}} (-NaN), but this is being returned as {{0x7fc0}} (+NaN), > causing the test to fail. > If this is in fact caused by Java's implementation of {{float}} and > {{double}}, then this should not be considered a hard failure, but rather an > expected failure which is ignored and does not cause the overall test to > fail. Provision for this type of case should be made in the test framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-9) AMQP type binary fails in QpidJms -> QpidJms test
[ https://issues.apache.org/jira/browse/QPIDIT-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-9: -- Priority: Minor (was: Major) > AMQP type binary fails in QpidJms -> QpidJms test > - > > Key: QPIDIT-9 > URL: https://issues.apache.org/jira/browse/QPIDIT-9 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Qpid Jms Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type binary fails in the QpidJms to QpidJms test with the following > error: > {noformat} > AssertionError: > sent:['', '12345', 'Hello, world!', > '\x01\x02\x03\x04\x05abcde\x80\x81\xfe\xff'] > received:['', '12345', 'Hello, world!', > '\x01\x02\x03\x04\x05abcde\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd'] > {noformat} > The underlying issue is that the {{String.getBytes()}} method used by the > ProtonJmsSender shim does not handle hex values > \x7f (which is the limit of > ASCII encoding), so some other means of processing the hex string into a > {{byte[]}} must be found. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-9) AMQP type binary fails in QpidJms -> QpidJms test
[ https://issues.apache.org/jira/browse/QPIDIT-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-9: -- Affects Version/s: 0.1.0 > AMQP type binary fails in QpidJms -> QpidJms test > - > > Key: QPIDIT-9 > URL: https://issues.apache.org/jira/browse/QPIDIT-9 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Qpid Jms Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type binary fails in the QpidJms to QpidJms test with the following > error: > {noformat} > AssertionError: > sent:['', '12345', 'Hello, world!', > '\x01\x02\x03\x04\x05abcde\x80\x81\xfe\xff'] > received:['', '12345', 'Hello, world!', > '\x01\x02\x03\x04\x05abcde\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd'] > {noformat} > The underlying issue is that the {{String.getBytes()}} method used by the > ProtonJmsSender shim does not handle hex values > \x7f (which is the limit of > ASCII encoding), so some other means of processing the hex string into a > {{byte[]}} must be found. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-8) Implement AMQP type array for ProtonPython shim
[ https://issues.apache.org/jira/browse/QPIDIT-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-8: -- Affects Version/s: 0.1.0 > Implement AMQP type array for ProtonPython shim > --- > > Key: QPIDIT-8 > URL: https://issues.apache.org/jira/browse/QPIDIT-8 > Project: Apache QPID Interoperability Test Suite > Issue Type: Task > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > The AMQP type array has not been implemented in the ProtonPython shim. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-7) AMQP type map fails ProtonPython -> ProtonPython
[ https://issues.apache.org/jira/browse/QPIDIT-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-7: -- Priority: Minor (was: Major) > AMQP type map fails ProtonPython -> ProtonPython > > > Key: QPIDIT-7 > URL: https://issues.apache.org/jira/browse/QPIDIT-7 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type map fails when run from ProtonPython to ProtonPython with the > following error: > {noformat} > AssertionError: > sent:[{}, {1: u'one', 2: u'two'}, {None: None, 1: False, '2': '2', False: > True}] > received:[{}, {1L: u'one', 2L: u'two'}, {False: True, 1L: False, '2': '2'}] > {noformat} > The map type is a complex type which allows embedding of other types, and the > command-line interpreter of the text representation of the map is likely > faulty. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-7) AMQP type map fails ProtonPython -> ProtonPython
[ https://issues.apache.org/jira/browse/QPIDIT-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-7: -- Affects Version/s: 0.1.0 > AMQP type map fails ProtonPython -> ProtonPython > > > Key: QPIDIT-7 > URL: https://issues.apache.org/jira/browse/QPIDIT-7 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type map fails when run from ProtonPython to ProtonPython with the > following error: > {noformat} > AssertionError: > sent:[{}, {1: u'one', 2: u'two'}, {None: None, 1: False, '2': '2', False: > True}] > received:[{}, {1L: u'one', 2L: u'two'}, {False: True, 1L: False, '2': '2'}] > {noformat} > The map type is a complex type which allows embedding of other types, and the > command-line interpreter of the text representation of the map is likely > faulty. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-5) AMQP type decimal32 fails ProtonPython -> ProtonPython
[ https://issues.apache.org/jira/browse/QPIDIT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-5: -- Priority: Minor (was: Major) > AMQP type decimal32 fails ProtonPython -> ProtonPython > -- > > Key: QPIDIT-5 > URL: https://issues.apache.org/jira/browse/QPIDIT-5 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type decimal32 fails when run from ProtonPython to ProtonPython with > the following error: > {{OverflowError: in method 'pn_data_put_decimal32', argument 2 of type > 'pn_decimal32_t'}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-6) AMQP type decimal64 fails ProtonPython -> ProtonPython
[ https://issues.apache.org/jira/browse/QPIDIT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-6: -- Priority: Minor (was: Major) > AMQP type decimal64 fails ProtonPython -> ProtonPython > -- > > Key: QPIDIT-6 > URL: https://issues.apache.org/jira/browse/QPIDIT-6 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type decimal64 fails when run from ProtonPython to ProtonPython with > the following error: > {{OverflowError: in method 'pn_data_put_decimal64', argument 2 of type > 'pn_decimal64_t'}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-6) AMQP type decimal64 fails ProtonPython -> ProtonPython
[ https://issues.apache.org/jira/browse/QPIDIT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-6: -- Affects Version/s: 0.1.0 > AMQP type decimal64 fails ProtonPython -> ProtonPython > -- > > Key: QPIDIT-6 > URL: https://issues.apache.org/jira/browse/QPIDIT-6 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type decimal64 fails when run from ProtonPython to ProtonPython with > the following error: > {{OverflowError: in method 'pn_data_put_decimal64', argument 2 of type > 'pn_decimal64_t'}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-5) AMQP type decimal32 fails ProtonPython -> ProtonPython
[ https://issues.apache.org/jira/browse/QPIDIT-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-5: -- Affects Version/s: 0.1.0 > AMQP type decimal32 fails ProtonPython -> ProtonPython > -- > > Key: QPIDIT-5 > URL: https://issues.apache.org/jira/browse/QPIDIT-5 > Project: Apache QPID Interoperability Test Suite > Issue Type: Bug > Components: Proton Python Shim >Affects Versions: 0.1.0 >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Minor > > The AMQP type decimal32 fails when run from ProtonPython to ProtonPython with > the following error: > {{OverflowError: in method 'pn_data_put_decimal32', argument 2 of type > 'pn_decimal32_t'}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org