[jira] [Commented] (PROTON-1732) [OSX] Enable swig for the Travis CI build

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310610#comment-16310610
 ] 

ASF GitHub Bot commented on PROTON-1732:


GitHub user RoddieKieley opened a pull request:

https://github.com/apache/qpid-proton/pull/135

PROTON-1732: [OSX] Enable swig for the Travis CI build

Minor update to enable swig for the OSX Travis CI. BUILD_PERL=OFF for the 
moment as it attempts to build i386 and fails on OSX.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/RoddieKieley/qpid-proton PROTON-1732

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/135.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #135


commit d88d23d0f8c4efcc4722ac5a87baef8e87227903
Author: Roddie Kieley 
Date:   2018-01-04T02:06:26Z

PROTON-1732: [OSX] Enable swig for the Travis CI build




> [OSX] Enable swig for the Travis CI build
> -
>
> Key: PROTON-1732
> URL: https://issues.apache.org/jira/browse/PROTON-1732
> Project: Qpid Proton
>  Issue Type: Sub-task
>  Components: proton-c
>Affects Versions: proton-c-0.19.0
> Environment: Travis CI
> Xcode 7.3, 9
>Reporter: Roddie Kieley
>Priority: Minor
> Fix For: proton-c-future
>
>
> Comparing the current travis builds for linux and osx we see that the linux 
> builds cover ruby whereas the osx builds do not. Swig is required for this to 
> occur.



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

[GitHub] qpid-proton pull request #135: PROTON-1732: [OSX] Enable swig for the Travis...

[RoddieKieley]

GitHub user RoddieKieley opened a pull request:

https://github.com/apache/qpid-proton/pull/135

PROTON-1732: [OSX] Enable swig for the Travis CI build

Minor update to enable swig for the OSX Travis CI. BUILD_PERL=OFF for the 
moment as it attempts to build i386 and fails on OSX.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/RoddieKieley/qpid-proton PROTON-1732

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/135.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #135


commit d88d23d0f8c4efcc4722ac5a87baef8e87227903
Author: Roddie Kieley 
Date:   2018-01-04T02:06:26Z

PROTON-1732: [OSX] Enable swig for the Travis CI build




---

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

[jira] [Created] (PROTON-1732) [OSX] Enable swig for the Travis CI build

[Roddie Kieley (JIRA)]

Roddie Kieley created PROTON-1732:
-

 Summary: [OSX] Enable swig for the Travis CI build
 Key: PROTON-1732
 URL: https://issues.apache.org/jira/browse/PROTON-1732
 Project: Qpid Proton
  Issue Type: Sub-task
Affects Versions: proton-c-0.19.0
 Environment: Travis CI
Xcode 7.3, 9
Reporter: Roddie Kieley
Priority: Minor


Comparing the current travis builds for linux and osx we see that the linux 
builds cover ruby whereas the osx builds do not. Swig is required for this to 
occur.



--
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] (PROTON-1729) [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version

[Roddie Kieley (JIRA)]

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

Roddie Kieley resolved PROTON-1729.
---
Resolution: Done

> [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version
> ---
>
> Key: PROTON-1729
> URL: https://issues.apache.org/jira/browse/PROTON-1729
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: proton-c-0.19.0
> Environment: OSX 10.11.6
> Xcode 7.3.1
>Reporter: Roddie Kieley
>Priority: Minor
>
> The release of 0.19.0 marks the first official tagged release that builds on 
> OSX "out of the box". A MacPorts Portfile for Qpid Proton was added as soon 
> as a commit became available that would build on OSX in the 0.18.1++ 
> timeframe and this should be updated to utilize the 0.19.0 release.



--
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] (PROTON-1729) [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version

[Roddie Kieley (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310551#comment-16310551
 ] 

Roddie Kieley commented on PROTON-1729:
---

PR [#1163|https://github.com/macports/macports-ports/pull/1163] merged to 
macports:master after successful [travis 
ci|https://travis-ci.org/macports/macports-ports/jobs/322752858] build.

> [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version
> ---
>
> Key: PROTON-1729
> URL: https://issues.apache.org/jira/browse/PROTON-1729
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: proton-c-0.19.0
> Environment: OSX 10.11.6
> Xcode 7.3.1
>Reporter: Roddie Kieley
>Priority: Minor
>
> The release of 0.19.0 marks the first official tagged release that builds on 
> OSX "out of the box". A MacPorts Portfile for Qpid Proton was added as soon 
> as a commit became available that would build on OSX in the 0.18.1++ 
> timeframe and this should be updated to utilize the 0.19.0 release.



--
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] (DISPATCH-906) Document Kerberos integration

[Ben Hardesty (JIRA)]

Ben Hardesty created DISPATCH-906:
-

 Summary: Document Kerberos integration
 Key: DISPATCH-906
 URL: https://issues.apache.org/jira/browse/DISPATCH-906
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Documentation
Reporter: Ben Hardesty
Assignee: Ben Hardesty


Document requirements and for accepting Kerberos authenticated connections.



--
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] (PROTON-1731) Build tests running with valgrind fail under fedora 27

[Andrew Stitcher (JIRA)]

Andrew Stitcher created PROTON-1731:
---

 Summary: Build tests running with valgrind fail under fedora 27
 Key: PROTON-1731
 URL: https://issues.apache.org/jira/browse/PROTON-1731
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
 Environment: Fedora 27
Reporter: Andrew Stitcher


Fedora 27 has a different arrangement for debug symbols than previous versions 
of Fedora and Debian and this can confuse valgrind into producing messages like:

{noformat}
--28388-- WARNING: Serious error when reading debug info
--28388-- When reading debug info from /usr/lib64/libkrb5support.so.0.1:
--28388-- get_Form_contents: DW_FORM_GNU_strp_alt used, but no alternate 
.debug_str
{noformat}

This confuses the tests because it is output they are not expecting and so the 
tests can fail.

The valgrind bug is https://bugs.kde.org/show_bug.cgi?id=387773



--
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] (PROTON-1718) (Proton-J) Custom Sasl

[Tim Taylor (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310063#comment-16310063
 ] 

Tim Taylor edited comment on PROTON-1718 at 1/3/18 6:55 PM:


I want to set aside the talk of adding extra threads to this problem. I don't 
think I will need to use separate threads for this scenario.

Instead, I want to drill down on part of your comment:

"When you 'send' for sasl (which doesnt actually send anything on the wire 
immediately, only later when the IO processing occurs) is indeed important 
since any IO work is only done explicitly at a stage of the thread processing 
the reactor (which is often after processing received data off the wire)."

Is this the only time when the reactor does IO processing? I would like my 
"send" calls to be processed, but there is no callback extended to the user 
that allows them to react in time to catch the reactor in this phase. I would 
imagine that there is some event that should be extended to users that allows 
them to insert their challenge response when a given challenge is received. 
Maybe it is one of the many BaseHandler events? Using sasl.Pending() isn't good 
enough to catch the reactor during this IO phase.

Is there a way to tell the reactor to do IO processing at some arbitrary 
reactor event (onReactorQuiesced, for example)?


was (Author: timtay):
I want to set aside the talk of adding extra threads to this problem. I don't 
think I will need to use separate threads for this scenario.

Instead, I want to drill down on part of your comment:

"When you 'send' for sasl (which doesnt actually send anything on the wire 
immediately, only later when the IO processing occurs) is indeed important 
since any IO work is only done explicitly at a stage of the thread processing 
the reactor (which is often after processing received data off the wire)."

Is this the only time when the reactor does IO processing? I would like my 
"send" calls to be processed, but there is no callback extended to the user 
that allows them to react in time to catch the reactor in this phase. I would 
imagine that there is some event that should be extended to users that allows 
them to insert their challenge response when a given challenge is received. 
Using sasl.Pending() isn't good enough to catch the reactor during this IO 
phase.

Is there a way to tell the reactor to do IO processing at some arbitrary 
reactor event (onReactorQuiesced, for example)?

> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
>  Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j 
> to use instead of being forced to use the default SaslImpl.java 
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it 
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this 
> way?



--
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] (PROTON-1718) (Proton-J) Custom Sasl

[Tim Taylor (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310063#comment-16310063
 ] 

Tim Taylor commented on PROTON-1718:


I want to set aside the talk of adding extra threads to this problem. I don't 
think I will need to use separate threads for this scenario.

Instead, I want to drill down on part of your comment:

"When you 'send' for sasl (which doesnt actually send anything on the wire 
immediately, only later when the IO processing occurs) is indeed important 
since any IO work is only done explicitly at a stage of the thread processing 
the reactor (which is often after processing received data off the wire)."

Is this the only time when the reactor does IO processing? I would like my 
"send" calls to be processed, but there is no callback extended to the user 
that allows them to react in time to catch the reactor in this phase. I would 
imagine that there is some event that should be extended to users that allows 
them to insert their challenge response when a given challenge is received. 
Using sasl.Pending() isn't good enough to catch the reactor during this IO 
phase.

Is there a way to tell the reactor to do IO processing at some arbitrary 
reactor event (onReactorQuiesced, for example)?

> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
>  Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j 
> to use instead of being forced to use the default SaslImpl.java 
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it 
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this 
> way?



--
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] (PROTON-1718) (Proton-J) Custom Sasl

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309971#comment-16309971
 ] 

Robbie Gemmell commented on PROTON-1718:


The reactor is expressly single threaded other than the wakeup method, you cant 
safely use it or its directly associated transport/connection-related objects 
from multiple threads at the same time. If you are using the run() method, then 
that thread is the only one that can use/update them, except to call wakeup, 
and if you block the reactor thread itself (e.g with a sleep) during operation 
for extended periods then it wont be able to actually send or receive anything 
further on the wire while thats happening.

When you 'send' for sasl (which doesnt actually send anything on the wire 
immediately, only later when the IO processing occurs) is indeed important 
since any IO work is only done explicitly at a stage of the thread processing 
the reactor (which is often after processing received data off the wire). The 
reactor model somewhat hides the engine and the IO mechanics from you, so while 
the proton engine API as originally created allows doing all this SASL stuff 
fairly simply, having the reactor API wrapped around it makes it difficult to 
use in this scenario. More so if you are trying to use multiple threads on top.

If you want to involve other threads you will need to coordinate between them. 
One way would appear to be scheduling a Handler of onTimerTask on the reactor 
that then completes the work when fired, or perhaps another would be calling 
the reactor wakeup and having an onReactorQuiesced handler somewhere able to 
process any work when called prior to it going back to blocking on its selector 
(or periodically since it wakes itself up every so often; a few seconds by 
default I think). A further option still might be adding your own 'Selectable' 
to the reactor and having that perform the desired processing as its called.

> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
>  Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j 
> to use instead of being forced to use the default SaslImpl.java 
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it 
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this 
> way?



--
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-8063) Please use https (SSL) for links to KEYS, hashes, sigs

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-8063.
--
Resolution: Fixed

The additional pages outwith the main download page have now been updated also, 
resolving.

> Please use https (SSL) for links to KEYS, hashes, sigs
> --
>
> Key: QPID-8063
> URL: https://issues.apache.org/jira/browse/QPID-8063
> Project: Qpid
>  Issue Type: Bug
>  Components: Website
> Environment: http://qpid.apache.org/download.html
>Reporter: Sebb
>Assignee: Robbie Gemmell
>Priority: Minor
>
> As the subject says: Please use https (SSL) for links to KEYS, hashes, sigs



--
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-6933) Factor out a JMS client neutral messaging test suite from system tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-6933:
---

Commit 6c0c5b1ffde7232b36a0b6b1422c7826323bff11 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=6c0c5b1 ]

QPID-6933: [System Tests] Refactor ObjectMessageClassWhitelistingTest as JMS 
1.1 system test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
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-6933) Factor out a JMS client neutral messaging test suite from system tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-6933:
---

Commit 52ee3bff008094e1bb95f65a0922e6be942003b8 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=52ee3bf ]

QPID-6933: [System Tests] Simplify LastValueQueueTest


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
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-6933) Factor out a JMS client neutral messaging test suite from system tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-6933:
---

Commit 81a3391d7af842c94857aef19994c8248c3f5bf3 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=81a3391 ]

QPID-6933: [System Tests] Fix failing tests


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
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-8068) [JMS AMQP 0-x] Change of noLocal on re-subscription of durable subscriber does not re-create the subscription

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-8068:


 Summary: [JMS AMQP 0-x] Change of noLocal on re-subscription of 
durable subscriber does not re-create the subscription
 Key: QPID-8068
 URL: https://issues.apache.org/jira/browse/QPID-8068
 Project: Qpid
  Issue Type: Bug
  Components: JMS AMQP 0-x
Affects Versions: qpid-java-6.1.5, qpid-java-client-0-x-6.3.0, 
qpid-java-6.0.8
Reporter: Alex Rudyy


As per  JMS 1.1 specification section "6.11.1 Durable TopicSubscriber"
{quote}
A client can change an existing durable subscription by creating a durable
TopicSubscriber with the same name and a new topic and/or message selector,
or NoLocal attribute. Changing a durable subscription is equivalent to deleting
and recreating it.
{quote}

The existing client does not re-create the subscription on change of noLocal.

The workaround for the issue would be to unsubscribe and subscribe again.



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