[jira] [Commented] (PROTON-1393) Memory leak with delayed settlement

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PROTON-1393:


Github user jkamke closed the pull request at:

https://github.com/apache/qpid-proton-j/pull/1


> Memory leak with delayed settlement
> ---
>
> Key: PROTON-1393
> URL: https://issues.apache.org/jira/browse/PROTON-1393
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.16.0
>Reporter: Jonathan Kamke
>
> {{DeliveryImpl}} manages several doubly linked lists (of links, work and 
> transportWork). However it does not function properly if removal is done out 
> of order. It leaves object references in the next/previous pointers which on 
> a large scale inhibit the system from garbage collecting these object, namely 
> the {{DeliveryImpl}} object graph.
> In practice this was discovered when message consumers delay settlement of 
> messages until after a period of time elapses (i.e. some async work is done 
> in another thread). This causes out of order settlement to occur, leaving 
> object references. Eventually the JVM will run out of memory and the process 
> will crash. The heap can be examined to discover a large number of 
> {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-proton-j issue #1: Memory leak with delayed settlement

[jkamke]

Github user jkamke commented on the issue:

https://github.com/apache/qpid-proton-j/pull/1
  
Thanks @gemmellr. Closing in favor of master based changes in 
apache/qpid-proton-j/issues/2.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-proton-j pull request #1: Memory leak with delayed settlement

[jkamke]

Github user jkamke closed the pull request at:

https://github.com/apache/qpid-proton-j/pull/1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-proton-j pull request #2: Delivery link leak

[jkamke]

GitHub user jkamke opened a pull request:

https://github.com/apache/qpid-proton-j/pull/2

Delivery link leak

Supersedes apache/qpid-proton-j/pull/1 for 
https://issues.apache.org/jira/browse/PROTON-1393
 

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

$ git pull https://github.com/jkamke/qpid-proton-j delivery-link-leak

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

https://github.com/apache/qpid-proton-j/pull/2.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 #2


commit 3c315a31548aa8ce2570b61eda3cfecf783b4f72
Author: Robert Gemmell 
Date:   2016-12-08T15:37:59Z

PROTON-1374: update versions for 0.16.0 (RC1)

commit b942d5636479b3ba51a842ee2734171e5722a9bd
Author: Robert Gemmell 
Date:   2016-12-08T17:33:40Z

PROTON-1374: bump versions to 0.16.1-SNAPSHOT

commit 059322cb19c77514f58c62fa7dbd580faf70cf7a
Author: JK 
Date:   2017-01-19T17:15:08Z

fix memory leak by cleaning up references and removing links safely

commit 45009610ef8af0d558cd0a1adf1797525db2522c
Author: JK 
Date:   2017-01-20T02:31:12Z

test for memory leak

commit 41151a52dbd30cfe0d5471fb7bfe1502305578a4
Author: JK 
Date:   2017-01-20T02:32:48Z

attribution for verifier

commit 541d1974cc938ac64ffb9583ab8351dcd8072fab
Author: JK 
Date:   2017-01-25T18:22:41Z

Fixes #1 and addresses https://issues.apache.org/jira/browse/PROTON-1393 
against master




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (PROTON-1393) Memory leak with delayed settlement

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PROTON-1393:


GitHub user jkamke opened a pull request:

https://github.com/apache/qpid-proton-j/pull/2

Delivery link leak

Supersedes apache/qpid-proton-j/pull/1 for 
https://issues.apache.org/jira/browse/PROTON-1393
 

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

$ git pull https://github.com/jkamke/qpid-proton-j delivery-link-leak

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

https://github.com/apache/qpid-proton-j/pull/2.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 #2


commit 3c315a31548aa8ce2570b61eda3cfecf783b4f72
Author: Robert Gemmell 
Date:   2016-12-08T15:37:59Z

PROTON-1374: update versions for 0.16.0 (RC1)

commit b942d5636479b3ba51a842ee2734171e5722a9bd
Author: Robert Gemmell 
Date:   2016-12-08T17:33:40Z

PROTON-1374: bump versions to 0.16.1-SNAPSHOT

commit 059322cb19c77514f58c62fa7dbd580faf70cf7a
Author: JK 
Date:   2017-01-19T17:15:08Z

fix memory leak by cleaning up references and removing links safely

commit 45009610ef8af0d558cd0a1adf1797525db2522c
Author: JK 
Date:   2017-01-20T02:31:12Z

test for memory leak

commit 41151a52dbd30cfe0d5471fb7bfe1502305578a4
Author: JK 
Date:   2017-01-20T02:32:48Z

attribution for verifier

commit 541d1974cc938ac64ffb9583ab8351dcd8072fab
Author: JK 
Date:   2017-01-25T18:22:41Z

Fixes #1 and addresses https://issues.apache.org/jira/browse/PROTON-1393 
against master




> Memory leak with delayed settlement
> ---
>
> Key: PROTON-1393
> URL: https://issues.apache.org/jira/browse/PROTON-1393
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.16.0
>Reporter: Jonathan Kamke
>
> {{DeliveryImpl}} manages several doubly linked lists (of links, work and 
> transportWork). However it does not function properly if removal is done out 
> of order. It leaves object references in the next/previous pointers which on 
> a large scale inhibit the system from garbage collecting these object, namely 
> the {{DeliveryImpl}} object graph.
> In practice this was discovered when message consumers delay settlement of 
> messages until after a period of time elapses (i.e. some async work is done 
> in another thread). This causes out of order settlement to occur, leaving 
> object references. Eventually the JVM will run out of memory and the process 
> will crash. The heap can be examined to discover a large number of 
> {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7635) [Java Broker] If ANONYMOUS-RELAY finds the destination it should defer the delivery outcome to the destination

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7635:
--

Can some more information be added to this JIRA please to help me understand 
the background and the current behaviour?

> [Java Broker] If ANONYMOUS-RELAY finds the destination it should defer the 
> delivery outcome to the destination
> --
>
> Key: QPID-7635
> URL: https://issues.apache.org/jira/browse/QPID-7635
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-7.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-7.0
>
>
> On publishing message using ANONYMOUS-RELAY when message is delivered to 
> queue with binding having filters not accepting the message the delivery 
> outcome is determined by anonymous relay (currently REJECTED) instead of 
> queue or exchange. If ANONYMOUS-RELAY finds the destination it should defer 
> the delivery outcome to the destination.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7634:
-
Description: 
When AMQP 1.0 client sends the Flow command with drain=true and queue is empty 
the Broker does not respond if prefetch is 0.

The following snippet reproduces the issue
{code}
Connection connection = factory.createConnection(username, password);
connection.start();

Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer messageConsumer = session.createConsumer(queue);

TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); // 
<-- times out
{code}

The broker logs
{noformat}
2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
RECV[/127.0.0.1:51108|1] : 
Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
 amqp:rejected:list, amqp:released:list, 
amqp:modified:list],capabilities=[queue, global]},target=Target{}}
2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
(o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' with 
arguments 
'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
 ], 
consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
 optionSet=[ACQUIRES, SEES_REQUEUES]']
2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
(o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
(o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
default: ALLOWED
2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
(o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, 
type=Consumer]']
2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
(o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, 
type=Consumer]'] performed successfully with result: null
2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) - 
[con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
SUB-1001 : Create
2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
(o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with arguments 
'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
 ], 
consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
 optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue, 
type=Consumer]
2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
SEND[/127.0.0.1:51108|1] : 
Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
 amqp:rejected:list, amqp:released:list, 
amqp:modified:list],capabilities=[queue]},target=Target{},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}}
2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
(o.a.q.s.t.NonBlockingConnection) - Written 251 bytes
2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
(o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s)
2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] 
(o.a.q.s.t.NonBlockingConnection) - Read 34 byte(s)
2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
RECV[/127.0.0.1:51108|1] : 
Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=1,outgoingWindow=2147483647,handle=1,deliveryCount=0,linkCredit=1,drain=true}
2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] 
(o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s)
2017-01-24 11:05:58,162 DEBUG [IO-/127.0.0.1:51108] 
(o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s)
...
{noformat}


Relevant part of the spec:

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-flow-control

bq. If the sender's drain flag is set and there are no available messages, the 
sender MUST advance its delivery-count until link-credit is zero, and send its 
updated flow state to the receiver.



  was:
When AMQP 1.0 client sends the Flow command with drain=true and queue is empty 
the Broker 

[jira] [Updated] (PROTON-1393) Memory leak with delayed settlement

[Jonathan Kamke (JIRA)]

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

Jonathan Kamke updated PROTON-1393:
---
Description: 
{{DeliveryImpl}} manages several doubly linked lists (of links, work and 
transportWork). However it does not function properly if removal is done out of 
order. It leaves object references in the next/previous pointers which on a 
large scale inhibit the system from garbage collecting these object, namely the 
{{DeliveryImpl}} object graph.

In practice this was discovered when message consumers delay settlement of 
messages until after a period of time elapses (i.e. some async work is done in 
another thread). This causes out of order settlement to occur, leaving object 
references. Eventually the JVM will run out of memory and the process will 
crash. The heap can be examined to discover a large number of {{settled}} 
{{DeliveryImpl}}s which are holding references to themselves.

  was:If message consumers delay settlement of messages until after a period of 
time elapses (i.e. some work is done), then the number of {{DeliveryImpl}}(s) 
in the heap will rise. Eventually the JVM will run out of memory and the 
process will crash.


> Memory leak with delayed settlement
> ---
>
> Key: PROTON-1393
> URL: https://issues.apache.org/jira/browse/PROTON-1393
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.16.0
>Reporter: Jonathan Kamke
>
> {{DeliveryImpl}} manages several doubly linked lists (of links, work and 
> transportWork). However it does not function properly if removal is done out 
> of order. It leaves object references in the next/previous pointers which on 
> a large scale inhibit the system from garbage collecting these object, namely 
> the {{DeliveryImpl}} object graph.
> In practice this was discovered when message consumers delay settlement of 
> messages until after a period of time elapses (i.e. some async work is done 
> in another thread). This causes out of order settlement to occur, leaving 
> object references. Eventually the JVM will run out of memory and the process 
> will crash. The heap can be examined to discover a large number of 
> {{settled}} {{DeliveryImpl}}s which are holding references to themselves.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (PROTON-1393) Memory leak with delayed settlement

[Jonathan Kamke (JIRA)]

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

Jonathan Kamke updated PROTON-1393:
---
Description: 
{{DeliveryImpl}} manages several doubly linked lists (of links, work and 
transportWork). However it does not function properly if removal is done out of 
order. It leaves object references in the next/previous pointers which on a 
large scale inhibit the system from garbage collecting these object, namely the 
{{DeliveryImpl}} object graph.

In practice this was discovered when message consumers delay settlement of 
messages until after a period of time elapses (i.e. some async work is done in 
another thread). This causes out of order settlement to occur, leaving object 
references. Eventually the JVM will run out of memory and the process will 
crash. The heap can be examined to discover a large number of {{settled}} 
{{DeliveryImpl}} s which are holding references to themselves.

  was:
{{DeliveryImpl}} manages several doubly linked lists (of links, work and 
transportWork). However it does not function properly if removal is done out of 
order. It leaves object references in the next/previous pointers which on a 
large scale inhibit the system from garbage collecting these object, namely the 
{{DeliveryImpl}} object graph.

In practice this was discovered when message consumers delay settlement of 
messages until after a period of time elapses (i.e. some async work is done in 
another thread). This causes out of order settlement to occur, leaving object 
references. Eventually the JVM will run out of memory and the process will 
crash. The heap can be examined to discover a large number of {{settled}} 
{{DeliveryImpl}}s which are holding references to themselves.


> Memory leak with delayed settlement
> ---
>
> Key: PROTON-1393
> URL: https://issues.apache.org/jira/browse/PROTON-1393
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.16.0
>Reporter: Jonathan Kamke
>
> {{DeliveryImpl}} manages several doubly linked lists (of links, work and 
> transportWork). However it does not function properly if removal is done out 
> of order. It leaves object references in the next/previous pointers which on 
> a large scale inhibit the system from garbage collecting these object, namely 
> the {{DeliveryImpl}} object graph.
> In practice this was discovered when message consumers delay settlement of 
> messages until after a period of time elapses (i.e. some async work is done 
> in another thread). This causes out of order settlement to occur, leaving 
> object references. Eventually the JVM will run out of memory and the process 
> will crash. The heap can be examined to discover a large number of 
> {{settled}} {{DeliveryImpl}} s which are holding references to themselves.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (PROTON-1393) Memory leak with delayed settlement

[Jonathan Kamke (JIRA)]

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

Jonathan Kamke updated PROTON-1393:
---
Description: 
{{DeliveryImpl}} manages several doubly linked lists (of links, work and 
transportWork). However it does not function properly if removal is done out of 
order. It leaves object references in the next/previous pointers which on a 
large scale inhibit the system from garbage collecting these object, namely the 
{{DeliveryImpl}} object graph.

In practice this was discovered when message consumers delay settlement of 
messages until after a period of time elapses (i.e. some async work is done in 
another thread). This causes out of order settlement to occur, leaving object 
references. Eventually the JVM will run out of memory and the process will 
crash. The heap can be examined to discover a large number of {{settled}} 
{{DeliveryImpl}}(s) which are holding references to themselves.

  was:
{{DeliveryImpl}} manages several doubly linked lists (of links, work and 
transportWork). However it does not function properly if removal is done out of 
order. It leaves object references in the next/previous pointers which on a 
large scale inhibit the system from garbage collecting these object, namely the 
{{DeliveryImpl}} object graph.

In practice this was discovered when message consumers delay settlement of 
messages until after a period of time elapses (i.e. some async work is done in 
another thread). This causes out of order settlement to occur, leaving object 
references. Eventually the JVM will run out of memory and the process will 
crash. The heap can be examined to discover a large number of {{settled}} 
{{DeliveryImpl}} s which are holding references to themselves.


> Memory leak with delayed settlement
> ---
>
> Key: PROTON-1393
> URL: https://issues.apache.org/jira/browse/PROTON-1393
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.16.0
>Reporter: Jonathan Kamke
>
> {{DeliveryImpl}} manages several doubly linked lists (of links, work and 
> transportWork). However it does not function properly if removal is done out 
> of order. It leaves object references in the next/previous pointers which on 
> a large scale inhibit the system from garbage collecting these object, namely 
> the {{DeliveryImpl}} object graph.
> In practice this was discovered when message consumers delay settlement of 
> messages until after a period of time elapses (i.e. some async work is done 
> in another thread). This causes out of order settlement to occur, leaving 
> object references. Eventually the JVM will run out of memory and the process 
> will crash. The heap can be examined to discover a large number of 
> {{settled}} {{DeliveryImpl}}(s) which are holding references to themselves.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-625) qdrouterd crashes if it can't find the python library

[Alan Conway (JIRA)]

Alan Conway created DISPATCH-625:


 Summary: qdrouterd crashes if it can't find the python library
 Key: DISPATCH-625
 URL: https://issues.apache.org/jira/browse/DISPATCH-625
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.7.0
Reporter: Alan Conway
Assignee: Alan Conway


The router crashes if it can't find python library because the order of 
initialization has changed in main.c and the log source used to report the 
missingn python lib is not yet initialized.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-proton-j issue #1: Memory leak with delayed settlement

[gemmellr]

Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton-j/pull/1
  
I am in a F2F meeting (or travelling to/from it) all this week so I 
probably won't get a chance to look closely until next week, but I took a skim 
of this.

I can see from the changes that the issue is more subtle than the JIRA 
description actually indicates, so it would be useful to update that to be a 
bit clearer on the actual issue. E.g, settlement is effectively an explicit 'I 
am forgetting this delivery' step, so it is expected to retain deliveries when 
as yet unsettled. Retaining deliveries in memory that have been settled (and 
that fact actually processed by the Transport) would not, and the changes 
suggest there is scope for that to occur.

As an aside, we don't intend to do any 0.16.x releases, 0.17.0 will be the 
next release (fairly soon) for both proton[-c] and proton-j to cement their new 
independence, so changes for this will go on master.

Robbie


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (QPID-7642) [Java Broker] Create binding operations on exchanges should fail when invalid selector is provided as part of binding arguments

[ASF subversion and git services (JIRA)]

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

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

Commit 1780223 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1780223 ]

QPID-7642: Validate subscription filters on receiving attach

> [Java Broker] Create binding operations on exchanges should fail when invalid 
> selector is provided as part of binding arguments
> ---
>
> Key: QPID-7642
> URL: https://issues.apache.org/jira/browse/QPID-7642
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, 
> qpid-java-6.0.6, qpid-java-6.1.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-7.0
>
>
> When create binding operation is invoked with invalid selector provided as 
> part of binding arguments , the current exchange implementations react 
> differently on this  error condition:
> * fanout and direct exchanges create binding successfully without a selector
> * topic exchange throws ConnectionScopeRuntimeException
> * header exchange create "x-exclude-all" filter 
> The current behavior is inconsistent and not valid. The caller needs to be 
> notified about error condition by throwing a special exception which is not 
> ConnectionScopeRuntimeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7621) Target Java 8+, i.e. drop support for Java 7

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7621:
--

This will be just a modification to the Maven POMs and documentation. There is 
also reflective code in SSLUtil which can be eliminated in favour of a normal 
method call.

> Target Java 8+, i.e. drop support for Java 7
> 
>
> Key: QPID-7621
> URL: https://issues.apache.org/jira/browse/QPID-7621
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> Begin targeting Java 8 for the Qpid Broker for Java, i.e requiring Java 8+ to 
> build or use the broker, dropping support for Java 7.
> As discussed on the mailing lists:
> https://lists.apache.org/thread.html/00b8f739bd5a653ebb1ce096566fdaf35b0c8cfe749b2ba81bf7c38c@%3Cusers.qpid.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (QPID-7586) [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes that the buffer it is writing into is large enough

[Lorenz Quack (JIRA)]

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

Lorenz Quack reassigned QPID-7586:
--

Assignee: Lorenz Quack

> [Java Broker] [AMQP 1.0] Simplify the AMQP codec so that it always assumes 
> that the buffer it is writing into is large enough
> -
>
> Key: QPID-7586
> URL: https://issues.apache.org/jira/browse/QPID-7586
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Lorenz Quack
> Fix For: qpid-java-7.0
>
>
> The way the codec is used, we always allocate enough space for the entire 
> value to be written.  We can simplify the codec by separating the operation 
> to get the required buffer size from the implementation of writing to the 
> buffer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7642) [Java Broker] Create binding operations on exchanges should fail when invalid selector is provided as part of binding arguments

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-7642:


 Summary: [Java Broker] Create binding operations on exchanges 
should fail when invalid selector is provided as part of binding arguments
 Key: QPID-7642
 URL: https://issues.apache.org/jira/browse/QPID-7642
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.1.1, qpid-java-6.0.6, qpid-java-6.1, 
qpid-java-6.0.5, qpid-java-6.0.4, qpid-java-6.0.3, qpid-java-6.0.2, 
qpid-java-6.0.1, qpid-java-6.0, 0.32
Reporter: Alex Rudyy
 Fix For: qpid-java-7.0


When create binding operation is invoked with invalid selector provided as part 
of binding arguments , the current exchange implementations react differently 
on this  error condition:
* fanout and direct exchanges create binding successfully without a selector
* topic exchange throws ConnectionScopeRuntimeException
* header exchange create "x-exclude-all" filter 

The current behavior is inconsistent and not valid. The caller needs to be 
notified about error condition by throwing a special exception which is not 
ConnectionScopeRuntimeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7402) [Java Broker] https in default config

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7402:
--

Is the use case for development?   If so, I think we should add a alternative 
initial-config that defines a self signed certificate and two ports: HTTP 
serving both PLAIN/TLS and AMQP serving both PLAIN/TLS.   I think separately 
there should be a 'production' initial config that defines only TLS are refers 
to key material via system properties.

> [Java Broker] https in default config
> -
>
> Key: QPID-7402
> URL: https://issues.apache.org/jira/browse/QPID-7402
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-7.0
>
>
> Currently the broker ships with a default config that has a plain HTTP port 
> configured.
> Since basic auth over HTTP is disabled by default there is no way to remotely 
> configure the broker out of the box.
> I suggest to modify the default config to add a authprovider with self-signed 
> certificate and either replace the existing HTTP port or add a new HTTPS port.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Moved] (QPIDJMS-260) SCRAM SASL should verify the server-final message

[Keith Wall (JIRA)]

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

Keith Wall moved QPID-7641 to QPIDJMS-260:
--

Fix Version/s: (was: qpid-java-7.0)
  Component/s: (was: Java Client)
   qpid-jms-client
 Workflow: classic default workflow  (was: QPid Workflow)
  Key: QPIDJMS-260  (was: QPID-7641)
  Project: Qpid JMS  (was: Qpid)

> SCRAM SASL should verify the server-final message
> -
>
> Key: QPIDJMS-260
> URL: https://issues.apache.org/jira/browse/QPIDJMS-260
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Reporter: Keith Wall
>
> QPID-7282 addressed the issue that the Java Broker was not sending the 
> server-final message in the SCRAM-* SASL exchange, however this omission was 
> not causing the clients to fail, since they blindly accept the server's 
> acceptance of their credentials.
> Clients implementing SCRAM-* or similar protocols which include a client 
> verification step, should perform the verification of the server and fail or 
> warn (to be configured by a system property) if the verification does not 
> occur or it fails.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7641) SCRAM SASL should verify the server-final message

[Keith Wall (JIRA)]

Keith Wall created QPID-7641:


 Summary: SCRAM SASL should verify the server-final message
 Key: QPID-7641
 URL: https://issues.apache.org/jira/browse/QPID-7641
 Project: Qpid
  Issue Type: Improvement
  Components: Java Client
Reporter: Keith Wall
 Fix For: qpid-java-7.0


QPID-7282 addressed the issue that the Java Broker was not sending the 
server-final message in the SCRAM-* SASL exchange, however this omission was 
not causing the clients to fail, since they blindly accept the server's 
acceptance of their credentials.

Clients implementing SCRAM-* or similar protocols which include a client 
verification step, should perform the verification of the server and fail or 
warn (to be configured by a system property) if the verification does not occur 
or it fails.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7402) [Java Broker] https in default config

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7402:
-
Fix Version/s: (was: Future)
   qpid-java-7.0

> [Java Broker] https in default config
> -
>
> Key: QPID-7402
> URL: https://issues.apache.org/jira/browse/QPID-7402
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-7.0
>
>
> Currently the broker ships with a default config that has a plain HTTP port 
> configured.
> Since basic auth over HTTP is disabled by default there is no way to remotely 
> configure the broker out of the box.
> I suggest to modify the default config to add a authprovider with self-signed 
> certificate and either replace the existing HTTP port or add a new HTTPS port.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (QPID-7622) Separate Qpid Broker for Java and 0-x JMS Client in source tree

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-7622 at 1/25/17 1:46 PM:
---

We need to remember qpidversion.properties.  Both Broker and Client both load 
this file from the classpath.   At very least we must ensure that they 
reference unique resource names so that a new Broker can be co-located with an 
older client without the risk that one consumes the others 
{{qpidversion.properties}}.

This might be the moment to switch to:
maven-jar-plugins  addDefaultImplementationEntries
buildnumber-maven-plugin

and do away with qpidversion.properties altogether.


was (Author: k-wall):
We need to remember qpidversion.properties.  Both Broker and Client both load 
this file from the classpath.   At very least we need to ensure that they 
reference unique resources.

> Separate Qpid Broker for Java and 0-x JMS Client in source tree
> ---
>
> Key: QPID-7622
> URL: https://issues.apache.org/jira/browse/QPID-7622
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Client
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> As discussed here:
> http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-client-from-the-Qpid-for-Java-7-0-release-td7657770.html
> The proposal is to move the code and documentation that comprises the 0-x 
> client to its own SVN root:
> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
> The Java Broker and integration tests suites will remain at: 
> https://svn.apache.org/repos/asf/qpid/qpid-java
> Maven dependencies will be used to pull in the appropriate 0-x client for 
> integration testing purposes (as we already do with the Qpid JMS Client).
> The {{qpid-common}} module (and maven release artefact) will be eliminated.
> * Classes that the Broker requires will be moved into the class hierarchy of 
> the existing plugin modules {{amqp-0-10-protocol}} and {{amqp-0-8-protocol}} 
> e.g. {{org/apache/qpid/server/protocol/vx_y}}.*
> * Code that the 0-x client requires will be moved into the class hierarchy of 
> the client {{org/apache/qpid/client}}.
> This will allow the Broker and 0-x Client to co-exist in the same JVM without 
> class loading collision.   Class movements will be organised in such a way to 
> preserve SVN history.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7622) Separate Qpid Broker for Java and 0-x JMS Client in source tree

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7622:
--

We need to remember qpidversion.properties.  Both Broker and Client both load 
this file from the classpath.   At very least we need to ensure that they 
reference unique resources.

> Separate Qpid Broker for Java and 0-x JMS Client in source tree
> ---
>
> Key: QPID-7622
> URL: https://issues.apache.org/jira/browse/QPID-7622
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Client
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> As discussed here:
> http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-client-from-the-Qpid-for-Java-7-0-release-td7657770.html
> The proposal is to move the code and documentation that comprises the 0-x 
> client to its own SVN root:
> https://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
> The Java Broker and integration tests suites will remain at: 
> https://svn.apache.org/repos/asf/qpid/qpid-java
> Maven dependencies will be used to pull in the appropriate 0-x client for 
> integration testing purposes (as we already do with the Qpid JMS Client).
> The {{qpid-common}} module (and maven release artefact) will be eliminated.
> * Classes that the Broker requires will be moved into the class hierarchy of 
> the existing plugin modules {{amqp-0-10-protocol}} and {{amqp-0-8-protocol}} 
> e.g. {{org/apache/qpid/server/protocol/vx_y}}.*
> * Code that the 0-x client requires will be moved into the class hierarchy of 
> the client {{org/apache/qpid/client}}.
> This will allow the Broker and 0-x Client to co-exist in the same JVM without 
> class loading collision.   Class movements will be organised in such a way to 
> preserve SVN history.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7640) Migrate qpid-java svn to git

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7640:
--

When we do this, we will need to rework the qpidversion.properties as it 
includes the SVN revision number.

> Migrate qpid-java svn to git 
> -
>
> Key: QPID-7640
> URL: https://issues.apache.org/jira/browse/QPID-7640
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Java Client
>Reporter: Keith Wall
> Fix For: Future
>
>
> The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two 
> components that use SVN.  We should migrate from to GIT.   This will simplify 
> the site.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7640) Migrate qpid-java svn to git

[Keith Wall (JIRA)]

Keith Wall created QPID-7640:


 Summary: Migrate qpid-java svn to git 
 Key: QPID-7640
 URL: https://issues.apache.org/jira/browse/QPID-7640
 Project: Qpid
  Issue Type: Task
  Components: Java Broker, Java Client
Reporter: Keith Wall
 Fix For: Future


The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two 
components that use SVN.  We should migrate from to GIT.   This will simplify 
the site.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7568) [Java Broker] [AMQP 1.0] support Delayed Delivery with the JMS 2.0 client

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-7568.
--
Resolution: Fixed

> [Java Broker] [AMQP 1.0] support Delayed Delivery with the JMS 2.0 client
> -
>
> Key: QPID-7568
> URL: https://issues.apache.org/jira/browse/QPID-7568
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Robbie Gemmell
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
>
> QPID-7255 added a form of delayed delivery support for the Java broker and 
> AMQP 0-X JMS client, with a qpid specific annotation in the case of AMQP 1.0. 
> The AMQP 1.0 JMS client will also support this via addition of support for 
> JMS 2.0 (QPIDJMS-207), but with some differences than in QPID-7255, and it 
> would be good for the Java broker to support this too.
> The JMS 2.0 client can detect server support for the functionality in two 
> ways:
> - by the server offering a "DELAYED_DELIVERY"  connection capability
> - or, if the connection capability wasn't offered, by setting a desired 
> capability of "DELAYED_DELIVERY" on the sending link attach and inspecting if 
> it is offered in the response.
> If support for delivery delay was identified, when sending a message with a 
> producer configured with a delivery delay, the message will carry a 
> MessageAnnotation with _"x-opt-delivery-time"_ symbol key and long value 
> representing the time at which the message can be delivered to receivers as 
> the number of milliseconds since the epoch. If support was not identified, 
> the send will fail in order to reflect that the requested delay/delivery-time 
> can't be satisfied.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7609) JMS 2.0 systests module

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7609:
-
Status: Reviewable  (was: In Progress)

> JMS 2.0 systests module
> ---
>
> Key: QPID-7609
> URL: https://issues.apache.org/jira/browse/QPID-7609
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
> Attachments: 
> 0001-QPID-7609-Java-System-Tests-Add-a-JMS-2.0-systest-mo.patch
>
>
> We need the ability to test JMS 2.0 features end to end against the Java 
> Broker.  We will have a separate module that will be activated only on the 
> 1.0 AMQP test profiles.  It will contain tests written in terms of JMS 2.0 
> API.   AMQP Management will be used to perform any setup.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7625) [AMQP 1.0] Enforce lifetime-policy DeleteOnClose

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7625:
-
Summary: [AMQP 1.0] Enforce lifetime-policy DeleteOnClose   (was: [AMQP 
1.0] Enforce DeleteOnClose temporary queues are not deleted in response to JMS 
TemporaryQueue#delete)

> [AMQP 1.0] Enforce lifetime-policy DeleteOnClose 
> -
>
> Key: QPID-7625
> URL: https://issues.apache.org/jira/browse/QPID-7625
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> As shown by system test 
> {{TemporaryQueueTest#testExplictTemporaryQueueDeletion}}. When the 
> application calls {{TemporaryQueue#delete()}} the temporary queue ought to be 
> deleted immediately.  This currently does not happen.
> The following describes how sending links with certain properties are used to 
> establish temporary queues.
> https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf
> The Qpid JMS Client correctly sends the detach in response to the {{#delete}} 
> call, but it appears that the broker's AMQP 1.0 protocol layer does not 
> organise itself to act upon the {{expiryPolicy=link-detach}} once the link is 
> detached.
> The temporary queue _is_ deleted once the connection closes.
> The attach establishing the temporary queue looks like this:
> {noformat}
> Attach{name=qpid-jms:temp-queue-creator:ID:d591b0c0-169d-4895-a227-e1e18c9709ab:1:1,handle=0,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{},target=Target{durable=none,expiryPolicy=link-detach,timeout=0,dynamic=true,dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},capabilities=[temporary-queue]},incompleteUnsettled=false,initialDeliveryCount=0}
> {noformat}
> The detach sent by the client:
> {noformat}
> 017-01-17 12:22:24,665 DEBUG [IO-/127.0.0.1:62572] o.a.q.s.p.frame 
> RECV[/127.0.0.1:62572|0] : Detach{handle=0,closed=true}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7625) [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted in response to JMS TemporaryQueue#delete

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7625:
-
Summary: [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted 
in response to JMS TemporaryQueue#delete  (was: AMQP 1.0 temporary queues are 
not deleted in response to JMS TemporaryQueue#delete)

> [AMQP 1.0] Enforce DeleteOnClose temporary queues are not deleted in response 
> to JMS TemporaryQueue#delete
> --
>
> Key: QPID-7625
> URL: https://issues.apache.org/jira/browse/QPID-7625
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0
>
>
> As shown by system test 
> {{TemporaryQueueTest#testExplictTemporaryQueueDeletion}}. When the 
> application calls {{TemporaryQueue#delete()}} the temporary queue ought to be 
> deleted immediately.  This currently does not happen.
> The following describes how sending links with certain properties are used to 
> establish temporary queues.
> https://www.oasis-open.org/committees/download.php/56418/amqp-bindmap-jms-v1.0-wd06.pdf
> The Qpid JMS Client correctly sends the detach in response to the {{#delete}} 
> call, but it appears that the broker's AMQP 1.0 protocol layer does not 
> organise itself to act upon the {{expiryPolicy=link-detach}} once the link is 
> detached.
> The temporary queue _is_ deleted once the connection closes.
> The attach establishing the temporary queue looks like this:
> {noformat}
> Attach{name=qpid-jms:temp-queue-creator:ID:d591b0c0-169d-4895-a227-e1e18c9709ab:1:1,handle=0,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{},target=Target{durable=none,expiryPolicy=link-detach,timeout=0,dynamic=true,dynamicNodeProperties={lifetime-policy=DeleteOnClose{}},capabilities=[temporary-queue]},incompleteUnsettled=false,initialDeliveryCount=0}
> {noformat}
> The detach sent by the client:
> {noformat}
> 017-01-17 12:22:24,665 DEBUG [IO-/127.0.0.1:62572] o.a.q.s.p.frame 
> RECV[/127.0.0.1:62572|0] : Detach{handle=0,closed=true}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7638) Add ability to run JMS 2.0 TCK

[ASF subversion and git services (JIRA)]

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

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

Commit 1780176 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1780176 ]

QPID-7638: Move all steps required to run jms 2.0 tck into a separate profile

> Add ability to run JMS 2.0 TCK
> --
>
> Key: QPID-7638
> URL: https://issues.apache.org/jira/browse/QPID-7638
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
> Attachments: add-ability-to-run-tck2.diff
>
>
> We need the ability to run the TCK 2.0 against the Java Broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-624) Add Atomic operations support on Solaris

[Adel Boutros (JIRA)]

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

Adel Boutros updated DISPATCH-624:
--
Description: 
Full details here: 
http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html

*Methods added inspired from:*
https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_sub.html
https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_add.html
http://docs.oracle.com/cd/E19253-01/816-5168/atomic-ops-3c/index.html

  was:Full details here: 
http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html


> Add Atomic operations support on Solaris
> 
>
> Key: DISPATCH-624
> URL: https://issues.apache.org/jira/browse/DISPATCH-624
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
> Attachments: 0001-Add-Atomic-operations-for-Solaris.patch
>
>
> Full details here: 
> http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html
> *Methods added inspired from:*
> https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_sub.html
> https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_add.html
> http://docs.oracle.com/cd/E19253-01/816-5168/atomic-ops-3c/index.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-624) Add Atomic operations support on Solaris

[Adel Boutros (JIRA)]

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

Adel Boutros updated DISPATCH-624:
--
Attachment: 0001-Add-Atomic-operations-for-Solaris.patch

> Add Atomic operations support on Solaris
> 
>
> Key: DISPATCH-624
> URL: https://issues.apache.org/jira/browse/DISPATCH-624
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
> Attachments: 0001-Add-Atomic-operations-for-Solaris.patch
>
>
> Full details here: 
> http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-624) Add Atomic operations support on Solaris

[Adel Boutros (JIRA)]

Adel Boutros created DISPATCH-624:
-

 Summary: Add Atomic operations support on Solaris
 Key: DISPATCH-624
 URL: https://issues.apache.org/jira/browse/DISPATCH-624
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 0.7.0
Reporter: Adel Boutros


Full details here: 
http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7639) [AMQP 1.0] Implement large transaction guard (i.e. honour connection.maxUncommittedInMemorySize)

[Keith Wall (JIRA)]

Keith Wall created QPID-7639:


 Summary: [AMQP 1.0] Implement large transaction guard (i.e. honour 
connection.maxUncommittedInMemorySize)
 Key: QPID-7639
 URL: https://issues.apache.org/jira/browse/QPID-7639
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-7.0


The AMQP 1.0 layer does not have the ability to detect a large incoming 
transaction and warn and flow the messages to disk if limits are breached.  We 
should add it as this an important safe guard,

We are probably missing implementation here:
org.apache.qpid.server.protocol.v1_0.NodeReceivingDestination#send




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (QPID-7638) Add ability to run JMS 2.0 TCK

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-7638:


Assignee: Keith Wall  (was: Alex Rudyy)

Keith, 
Please review the changes

> Add ability to run JMS 2.0 TCK
> --
>
> Key: QPID-7638
> URL: https://issues.apache.org/jira/browse/QPID-7638
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: qpid-java-7.0
>
> Attachments: add-ability-to-run-tck2.diff
>
>
> We need the ability to run the TCK 2.0 against the Java Broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7638) Add ability to run JMS 2.0 TCK

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7638:
-
Status: Reviewable  (was: In Progress)

> Add ability to run JMS 2.0 TCK
> --
>
> Key: QPID-7638
> URL: https://issues.apache.org/jira/browse/QPID-7638
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-7.0
>
> Attachments: add-ability-to-run-tck2.diff
>
>
> We need the ability to run the TCK 2.0 against the Java Broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7638) Add ability to run JMS 2.0 TCK

[ASF subversion and git services (JIRA)]

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

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

Commit 1780155 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1780155 ]

QPID-7638: Add ability to run JMS 2.0 TCK

> Add ability to run JMS 2.0 TCK
> --
>
> Key: QPID-7638
> URL: https://issues.apache.org/jira/browse/QPID-7638
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-7.0
>
> Attachments: add-ability-to-run-tck2.diff
>
>
> We need the ability to run the TCK 2.0 against the Java Broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[ASF subversion and git services (JIRA)]

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

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

Commit 1780153 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1780153 ]

QPID-7546: [System Tests] Reclassify some excluded failures

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Attachments: 
> 0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch
>
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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