date:20180515

Re: Review Request 67139: treat attach after detach as new link

2018-05-15 Thread Gordon Sim


On 15/05/18 22:10, Alan Conway wrote:

Having trouble loggingn into reviewboard

I'm not sure if this is correct. If the link is not PN_LOCAL_CLOSED, then
the application is well within its rights to close() it.


I don't understand your point. This has no effect on what the 
application can do with any link objects it has. It only affects the 
link object that gets associated with a PN_LINK_REMOTE_OPEN event.



If we have re-used
it for another link that could close the wrong link.


Closing the link operates on a pn_link_t object the application created 
or got from an initial event. Where the peer sent an attach after a 
detach, this change causes the link object associated with the 
PN_LINK_REMOTE_OPEN event for the second attach to be a new link object, 
not the link object associated with the preceding detach, which is not 
in a usable state.



This would be the 3rd time we've changed this particular line of code in
the last few months,


I don't think so, git blame on master shows:

fd26ec66 proton-c/src/transport/transport.c (Gordon Sim 
2015-04-17 11:41:10 +0100 1268)



each time we find some new situation that fails. I'm
inclined to think we should never re-use a "dead" link, and instead find
out why proton is leaving these "dead" links lying around and fix that.


This change doesn't involve re-using a dead link. If there is a link 
with the same name that has been closed or detached by the peer it skips 
that link and therefore assumes a new link.


The change from the current code is that it *doesn't* try to reuse the 
'dead' link if the peer has closed (or detached) it, regardless of the 
local status. As the function ins only used for handling an incoming 
attach from the peer that seems correct to me.


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

Re: Review Request 67139: treat attach after detach as new link

2018-05-15 Thread Alan Conway

Having trouble loggingn into reviewboard

I'm not sure if this is correct. If the link is not PN_LOCAL_CLOSED, then
the application is well within its rights to close() it. If we have re-used
it for another link that could close the wrong link.

This would be the 3rd time we've changed this particular line of code in
the last few months, each time we find some new situation that fails. I'm
inclined to think we should never re-use a "dead" link, and instead find
out why proton is leaving these "dead" links lying around and fix that.

On Tue, May 15, 2018 at 3:02 PM, Gordon Sim  wrote:

> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67139/
> Review request for qpid, Alan Conway, Ganesh Murthy, Justin Ross, and Ted
> Ross.
> By Gordon Sim.
> *Bugs: * PROTON-1845 
> *Repository: * qpid-proton-git
> Description
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
>
> It would be better to treat this as starting a new link object.
>
> This fixes DISPATCH-994 and DISPATCH-997
>
> Diffs
>
>- c/src/core/transport.c (e0a2b5c)
>
> View Diff 
>

[jira] [Updated] (PROTON-1845) treat attach received after detach as implying new link

2018-05-15 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1845:

Component/s: proton-c

> treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (PROTON-1845) [c] Treat attach received after detach as implying new link

2018-05-15 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1845:

Summary: [c] Treat attach received after detach as implying new link   
(was: treat attach received after detach as implying new link )

> [c] Treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (PROTON-1845) treat attach received after detach as implying new link

2018-05-15 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1845:

Fix Version/s: (was: proton-j-0.28.0)
   proton-c-0.23.0

> treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach

2018-05-15 Thread Gordon Sim (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476363#comment-16476363
 ] 

Gordon Sim commented on DISPATCH-994:
-

I think this is fixed by https://issues.apache.org/jira/browse/PROTON-1845

> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf, 
> topic_test.py, topic_test_v2.py
>
>
> Link routing from router A through router B to a 'broker', and closing and 
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674== 
> ==25674== 
> ==25674== Process terminating with default action of signal 11 (SIGSEGV): 
> dumping core
> ==25674==  Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674==  If you believe this happened as a result of a stack
> ==25674==  overflow in your program's main thread (unlikely but
> ==25674==  possible), you can try to increase the size of the
> ==25674==  main thread stack using the --main-stacksize= flag.
> ==25674==  The main thread stack size used in this run was 8388608
> {noformat}
> To reproduce, start three routers with the attached config files, then run 
> the attached python test program.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-997) reusing link name from link closed uncleanly on link routes no longer works

2018-05-15 Thread Gordon Sim (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476362#comment-16476362
 ] 

Gordon Sim commented on DISPATCH-997:
-

I think this is fixed by https://issues.apache.org/jira/browse/PROTON-1845 

> reusing link name from link closed uncleanly on link routes no longer works
> ---
>
> Key: DISPATCH-997
> URL: https://issues.apache.org/jira/browse/DISPATCH-997
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: reuse_link_name.py, router-a.conf, router-b.conf, 
> router-c.conf
>
>
> Attach a link with a specific name that is routed from router A through 
> router B to a 'broker', then close the connection that attach was sent over 
> without detaching the link. Then try to reattach (on a new connection) with 
> the same link name. This fails as the attach does not get successfully routed 
> and now response is received back.
> Reproducer: run routers with attached configs router-a, router-b, router-c, 
> then run attached test script reuse_link_name.py. On 1.0.1, or direct against 
> a single router with no linkrouting, as expected the test iterates opening a 
> link the closing the connection. With 1.1.0 it gets stuck on second subscribe 
> attempt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1845) treat attach received after detach as implying new link

2018-05-15 Thread Gordon Sim (JIRA)


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

Gordon Sim commented on PROTON-1845:


Suggested change: https://reviews.apache.org/r/67139/

> treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-j-0.28.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Review Request 67139: treat attach after detach as new link

2018-05-15 Thread Gordon Sim


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

Review request for qpid, Alan Conway, Ganesh Murthy, Justin Ross, and Ted Ross.


Bugs: PROTON-1845
https://issues.apache.org/jira/browse/PROTON-1845


Repository: qpid-proton-git


Description
---

If a peer sends attach, detach, attach with the same link name in the second 
attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from the 
first attach. This link is not in a state where it can be reused.

It would be better to treat this as starting a new link object.

This fixes DISPATCH-994 and DISPATCH-997


Diffs
-

  c/src/core/transport.c e0a2b5c 


Diff: https://reviews.apache.org/r/67139/diff/1/


Testing
---


Thanks,

Gordon Sim

[jira] [Updated] (QPID-8141) [JMS AMQP 0-x] Sending message to address based destinations that matches the address of a previously resolved address fails

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8141:
-
Summary: [JMS AMQP 0-x] Sending message to address based destinations that 
matches the address of a previously resolved address fails  (was: [JMS AMQP 
0-x] Cannot publish message with address based destinations falsely identified 
as resolved due to unset routing key and exchange name)

> [JMS AMQP 0-x] Sending message to address based destinations that matches the 
> address of a previously resolved address fails
> 
>
> Key: QPID-8141
> URL: https://issues.apache.org/jira/browse/QPID-8141
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> Address based destination resolution functionality 
> {{AMQSession#resolveAddress}} sets a number of fields like {{routing key}}, 
> {{exchange name}}, etc as part of invocation of 
> {{AMQSession#setLegacyFieldsForQueueType}}. If destination object is 
> identified as resolved {{AMQSession#isResolved}} the essential fields are not 
> set on the destination object. As result, publishing attempts with such 
> destination objects will fail due to routing issues like the one reported 
> below:
> {noformat}
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:81)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:24)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:638)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:675)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:669)
>   at 
> org.apache.qpid.client.AMQSession_0_8.commitImpl(AMQSession_0_8.java:271)
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:913)
>   ... 6 more
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   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:105)
>   at 
> org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:531)
>   at 
> org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:460)
>   at 
> org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:66)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:480)
>   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)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The clients applications creating new destination objects on every publishing 
> attempt using the same session are impacted by the issue.
> The following code snippet demonstrate the problem:
> {code}
> MessageProducer messageProducer = session.createProducer(null);
> for (int i=0;i {
> Message message = session.createTextMessage("Test");
> messageProducer.send(session.createQueue(String.format(
> 
> "ADDR:test;{\"create\":\"always\",\"node\":{\"type\":\"queue\",\"durable\":true}}")),
>  message);
> }
> session.commit();
> {code}
> The work around would be to avoid creation of destination objects every time. 
> For example, Qpid JNDI properties can be used to declare and cache the 
> destination objects. 
> {code}
> destination.queue=ADDR:test;{"create":"always","node":"type":"queue","durable":true}}
> {code}
> {code}
>

[jira] [Updated] (QPID-8141) [JMS AMQP 0-x] Sending message to address based destinations that matches the address of a previously resolved address fails

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8141:
-
Description: 
Address based destination resolution functionality 
{{AMQSession#resolveAddress}} sets a number of fields like {{routing key}}, 
{{exchange name}}, etc as part of invocation of 
{{AMQSession#setLegacyFieldsForQueueType}}. If destination object is identified 
as resolved {{AMQSession#isResolved}} the essential fields are not set on the 
destination object. As result, publishing attempts with such destination 
objects will fail due to routing issues like the one reported below:
{noformat}
Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
message with exchange 'null' and routing key 'null' [error code: 312(no route)]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:81)
at 
org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:24)
at 
org.apache.qpid.client.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:638)
at 
org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:675)
at 
org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:669)
at 
org.apache.qpid.client.AMQSession_0_8.commitImpl(AMQSession_0_8.java:271)
at org.apache.qpid.client.AMQSession.commit(AMQSession.java:913)
... 6 more
Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
message with exchange 'null' and routing key 'null' [error code: 312(no route)]
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:105)
at 
org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118)
at 
org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:531)
at 
org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:460)
at 
org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:66)
at 
org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:480)
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)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The clients applications creating new destination objects on every publishing 
attempt using the same session are impacted by the issue.  Problems occurs for 
both 0-10 and 0-8..0-91.
 The following code snippet demonstrate the problem:
{code:java}
MessageProducer messageProducer = session.createProducer(null);
for (int i=0;i

[jira] [Created] (PROTON-1845) treat attach received after detach as implying new link

2018-05-15 Thread Gordon Sim (JIRA)

Gordon Sim created PROTON-1845:
--

 Summary: treat attach received after detach as implying new link 
 Key: PROTON-1845
 URL: https://issues.apache.org/jira/browse/PROTON-1845
 Project: Qpid Proton
  Issue Type: Bug
Reporter: Gordon Sim
Assignee: Gordon Sim
 Fix For: proton-j-0.28.0


If a peer sends attach, detach, attach with the same link name in the second 
attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from the 
first attach. This link is not in a state where it can be reused.

It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1833) [cpp] Crash on Windows after calling container::stop()

2018-05-15 Thread Cliff Jansen (JIRA)


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

Cliff Jansen commented on PROTON-1833:
--

While I could not reproduce, it is plausible that this was caused by 
https://issues.apache.org/jira/browse/PROTON-1844 and is now magically fixed.

> [cpp] Crash on Windows after calling container::stop()
> --
>
> Key: PROTON-1833
> URL: https://issues.apache.org/jira/browse/PROTON-1833
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.21.0
> Environment: Proton version : 0.21
> Windows 7 - 64 bits
> Visual studio 2010
>Reporter: Baptiste
>Assignee: Cliff Jansen
>Priority: Critical
>  Labels: crash, windows
> Fix For: proton-c-0.23.0
>
>
> Just creating a proton::container, listening locally on 
> [0.0.0.0:5672|http://0.0.0.0:5672/] and then call stop() on the container and 
> getting outside of the scope (object is then destroy) => the crash happen.
>   Where does it crash ? In *win_iocp.c*, the line in red
> void pn_proactor_free(pn_proactor_t *p)
> {  
> {color:#ff}DeleteTimerQueueEx(p->timer_queue, 
> INVALID_HANDLE_VALUE){color};
> DeleteCriticalSection(>timer_lock);  
> DeleteCriticalSection(>bind_lock);  
> proactor_shutdown(p);  
> delete p->reaper; 
> WSACleanup();  
> pn_collector_free(p->collector);  
> free(p);
> }
>  
> NOTE:
> A lot of tests failed on windows :
> 1>  The following tests FAILED:
> 1>        8 - cpp-container_test (Failed)
> 1>       10 - cpp-reconnect_test (Failed)
> 1>       21 - c-proactor-tests (Failed)
> 1>       23 - c-example-tests (Failed)
> 1>       24 - cpp-example-container (Failed)
> 1>       25 - cpp-example-container-ssl (Failed)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Closed] (DISPATCH-999) error querying large number of addresses with qdmanage

2018-05-15 Thread Gordon Sim (JIRA)


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

Gordon Sim closed DISPATCH-999.
---
Resolution: Duplicate

> error querying large number of addresses with qdmanage
> --
>
> Key: DISPATCH-999
> URL: https://issues.apache.org/jira/browse/DISPATCH-999
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Priority: Major
>
> Create 1 addresses on a router then try and run:
> qdmanage QUERY --type=address
>  against it. Get following error:
> MessageException: [-10]: data error: (null)
> This appears to be a decode error in proton-c. The message is received in 
> several transfer fragments.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (PROTON-1844) Windows proactor memory corruption on cleanup

2018-05-15 Thread Cliff Jansen (JIRA)


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

Cliff Jansen resolved PROTON-1844.
--
Resolution: Fixed

> Windows proactor memory corruption on cleanup
> -
>
> Key: PROTON-1844
> URL: https://issues.apache.org/jira/browse/PROTON-1844
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Same code as that affected in in epoll, so same fix required for PROTON-1773



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (PROTON-1514) [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled

2018-05-15 Thread Cliff Jansen (JIRA)


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

Cliff Jansen resolved PROTON-1514.
--
Resolution: Fixed

> [proton-c] When last frame of multi-frame transfer has settled=true, Proton 
> still considers delivery as unsettled
> -
>
> Key: PROTON-1514
> URL: https://issues.apache.org/jira/browse/PROTON-1514
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.17.0
>Reporter: Ganesh Murthy
>Assignee: Cliff Jansen
>Priority: Major
>  Labels: framing
> Fix For: proton-c-0.23.0
>
>
> I have a situation where a receiver (proton python's simple_recv.py) is 
> receiving a multi-frame transfer from a Dispatch Router. The settled flag is 
> false on all the transfer frames except on the last frame which has 
> settled=true as seen here -
> {noformat}
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=false, more=true] (16351) "g here33227Long string here33228Long 
> string here33229Long string here33230Long string here33231Long string 
> here33232Long string here33233Long string here33234Long string here33235Long 
> string here33236Long string here33237Long string here33238Long string 
> here33239Long string here33240Long string here33241Long string here33242Long 
> string here33243Long string here33244Long string here33245Long string 
> here33246Long string here33247Long string here33248Long string here33249Long 
> string here33250Long string here33251Long string here33252Long string 
> here33253Long string here33254Long string here33255Long string here33256Long 
> string here33257Long string here33258Long string here33259Long string 
> here33260Long string here33261Long string here33262Long string here33263Long 
> string here33264Long string here33265Long string here33266Long string 
> here33267Long string here33268Long string here33269Long string here33270Long 
> string here33271Long string here33272Long string here33273Long string 
> here33274Long string here33275Lon"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=false, more=true] (49053) "ng string here34006Long string 
> here34007Long string here34008Long string here34009Long string here34010Long 
> string here34011Long string here34012Long string here34013Long string 
> here34014Long string here34015Long string here34016Long string here34017Long 
> string here34018Long string here34019Long string here34020Long string 
> here34021Long string here34022Long string here34023Long string here34024Long 
> string here34025Long string here34026Long string here34027Long string 
> here34028Long string here34029Long string here34030Long string here34031Long 
> string here34032Long string here34033Long string here34034Long string 
> here34035Long string here34036Long string here34037Long string here34038Long 
> string here34039Long string here34040Long string here34041Long string 
> here34042Long string here34043Long string here34044Long string here34045Long 
> string here34046Long string here34047Long string here34048Long string 
> here34049Long string here34050Long string here34051Long string here34052Long 
> string here34053Long string here"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=false, more=true] (98106) "1Long string here36342Long string 
> here36343Long string here36344Long string here36345Long string here36346Long 
> string here36347Long string here36348Long string here36349Long string 
> here36350Long string here36351Long string here36352Long string here36353Long 
> string here36354Long string here36355Long string here36356Long string 
> here36357Long string here36358Long string here36359Long string here36360Long 
> string here36361Long string here36362Long string here36363Long string 
> here36364Long string here36365Long string here36366Long string here36367Long 
> string here36368Long string here36369Long string here36370Long string 
> here36371Long string here36372Long string here36373Long string here36374Long 
> string here36375Long string here36376Long string here36377Long string 
> here36378Long string here36379Long string here36380Long string here36381Long 
> string here36382Long string here36383Long string here36384Long string 
> here36385Long string here36386Long string here36387Long string here36388Long 
> string here36389Long string h"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0, 
>

[GitHub] qpid-dispatch pull request #304: Dispatch 990 Use patterns for policy vhost ...

2018-05-15 Thread ChugR

GitHub user ChugR opened a pull request:

https://github.com/apache/qpid-dispatch/pull/304

Dispatch 990 Use patterns for policy vhost hostnames

This adds all the code (schema, management, run time) and supporting self 
tests and old style doc.
This does not add anything to doc/new-book. I will coordinate that with 
@bhardesty

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

$ git pull https://github.com/ChugR/qpid-dispatch DISPATCH-990

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

https://github.com/apache/qpid-dispatch/pull/304.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 #304


commit 32b06d23e29a692f2821f39d02be0f9d092b1648
Author: Chuck Rolke 
Date:   2018-05-08T14:37:35Z

DISPATCH-990: vhost hostname patterns management interface

commit 862b0214991a8d4a6145b5a50980d7613941b2e5
Author: Chuck Rolke 
Date:   2018-05-08T17:46:45Z

DISPATCH-990: reduce line lengths

commit 10ad8cf370412ec424f92e1a3db0aee031f4afc4
Author: Chuck Rolke 
Date:   2018-05-10T14:17:21Z

DISPATCH-990: Reorder config steps to init policy

Policy manager needs some setup before vhosts are processed.

commit e1ae8d3022d680775a5f441ea677b1498453ee15
Author: Chuck Rolke 
Date:   2018-05-10T19:41:21Z

DISPATCH-990: Add c code to support tree hostname lookups

commit f90c2a805d663fb2ea15a0fec7c70c16ce0aa1aa
Author: Chuck Rolke 
Date:   2018-05-11T13:22:24Z

DISPATCH-990: Add/remove policy hostname tree entries

Tie hostname lookup tree to life cycle of policy rulesets.

commit f17631cbe7a695fb4492a4437289d82a1a89a1c0
Author: Chuck Rolke 
Date:   2018-05-11T15:10:49Z

DISPATCH-990: integrate the pattern match with vhost lookups

commit 9c0a09d793795acbc165df37a45f8fa86329da0f
Author: Chuck Rolke 
Date:   2018-05-14T16:31:13Z

DISPATCH-990: Reject add of vhost that has pattern conflict.

Add self test showing how conflicts are managed.

commit 2b0f3d066428f5c13eed83848f017c39ca56f565
Author: Chuck Rolke 
Date:   2018-05-14T16:57:20Z

DISPATCH-990: Fix locks so hostname adds are atomic

commit 82cef3abff91857871ba7e9ca88177a39db0f7a0
Author: Chuck Rolke 
Date:   2018-05-14T18:11:30Z

DISPATCH-990: Add hostname translation to settings lookup

commit 415b4568ecac113f3ea4212507407dba03f7cdd1
Author: Chuck Rolke 
Date:   2018-05-14T19:56:58Z

DISPATCH-990: Add hostname pattern self test

Remove stray variables from log message.

commit 8712cabdf8f37dddc7f8d1ffc4792fbd177f050d
Author: Chuck Rolke 
Date:   2018-05-14T20:14:03Z

DISPATCH-990: add policy dir to support self test

commit 63a56d6052e747a0043df621a67805989de5d255
Author: Chuck Rolke 
Date:   2018-05-15T14:43:44Z

DISPATCH-990: Document name pattern match feature in old book.

Rename and touch up configuration settings to make docs read better.




---

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

[jira] [Issue Comment Deleted] (QPID-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core

2018-05-15 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated QPID-8184:
---
Comment: was deleted

(was: Commit from Kim van der Riet with incorrect tag QPIDIT-8184 instead of 
QPID-8184:

QPIDIT-8184: Second part of fix: Change error handling for EFP exceptions such 
that the broker shuts down more cleanly without a spurious segfault. Also 
addeed tests to the linearstore test suite which forces such errors and checks 
that they are handles correctly. A minor update to brokertest.py fixes tests 
which use the EXPECT_EXIT_FAIL flag.

See: 
[https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=7a47046b5a24461c6acf3381147278749cadb745|https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=7a47046b5a24461c6acf3381147278749cadb745])

> [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error 
> followed by core
> 
>
> Key: QPID-8184
> URL: https://issues.apache.org/jira/browse/QPID-8184
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> Some users are experiencing difficulty recovering the store, especially when 
> there are a large  number of queues (several thousand). The log files show 
> the following pattern:
> {{JERR_EFP_BADEFPDIRNAME}} in which some arbitrary number which is not 
> divisible by 4 is being used as the EFP file size (called EFP directory in 
> the log), followed by a segfault:
> {noformat}
> May 4 18:55:00 somehostname qpidd[6240]: 2018-05-04 18:55:00 [Store] warning 
> Linear Store: EmptyFilePool create failed: jexception 0x0d03 
> EmptyFilePool::fileSizeKbFromDirName() threw JERR_EFP_BADEFPDIRNAME: Bad 
> Empty File Pool directory name (must be 'NNNk', where NNN is a number which 
> is a multiple of 4) (Partition: 1; EFP directory: '9k')
> May 4 18:55:00 somehostname kernel: qpidd[6240]: segfault at 10 ip 
> 7f4219af8e19 sp 7ffc227a6350 error 4 in 
> linearstore.so[7f4219ac4000+bd000]{noformat}
>  In the event that the random number _is_ divisible by 4, a randomly sized 
> directory containing no files may appear in the partition EFP.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core

2018-05-15 Thread ASF subversion and git services (JIRA)


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

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

Commit d490824a6d63841876ecc8b92b26f46622bf1f2f in qpid-cpp's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=d490824 ]

QPID-8184: Second part of fix: Change error handling for EFP exceptions such 
that the broker shuts down more cleanly without a spurious segfault. Also 
addeed tests to the linearstore test suite which forces such errors and checks 
that they are handles correctly. A minor update to brokertest.py fixes tests 
which use the EXPECT_EXIT_FAIL flag.


> [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error 
> followed by core
> 
>
> Key: QPID-8184
> URL: https://issues.apache.org/jira/browse/QPID-8184
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> Some users are experiencing difficulty recovering the store, especially when 
> there are a large  number of queues (several thousand). The log files show 
> the following pattern:
> {{JERR_EFP_BADEFPDIRNAME}} in which some arbitrary number which is not 
> divisible by 4 is being used as the EFP file size (called EFP directory in 
> the log), followed by a segfault:
> {noformat}
> May 4 18:55:00 somehostname qpidd[6240]: 2018-05-04 18:55:00 [Store] warning 
> Linear Store: EmptyFilePool create failed: jexception 0x0d03 
> EmptyFilePool::fileSizeKbFromDirName() threw JERR_EFP_BADEFPDIRNAME: Bad 
> Empty File Pool directory name (must be 'NNNk', where NNN is a number which 
> is a multiple of 4) (Partition: 1; EFP directory: '9k')
> May 4 18:55:00 somehostname kernel: qpidd[6240]: segfault at 10 ip 
> 7f4219af8e19 sp 7ffc227a6350 error 4 in 
> linearstore.so[7f4219ac4000+bd000]{noformat}
>  In the event that the random number _is_ divisible by 4, a randomly sized 
> directory containing no files may appear in the partition EFP.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (QPID-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core

2018-05-15 Thread Kim van der Riet (JIRA)


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

Kim van der Riet resolved QPID-8184.

Resolution: Fixed

> [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error 
> followed by core
> 
>
> Key: QPID-8184
> URL: https://issues.apache.org/jira/browse/QPID-8184
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> Some users are experiencing difficulty recovering the store, especially when 
> there are a large  number of queues (several thousand). The log files show 
> the following pattern:
> {{JERR_EFP_BADEFPDIRNAME}} in which some arbitrary number which is not 
> divisible by 4 is being used as the EFP file size (called EFP directory in 
> the log), followed by a segfault:
> {noformat}
> May 4 18:55:00 somehostname qpidd[6240]: 2018-05-04 18:55:00 [Store] warning 
> Linear Store: EmptyFilePool create failed: jexception 0x0d03 
> EmptyFilePool::fileSizeKbFromDirName() threw JERR_EFP_BADEFPDIRNAME: Bad 
> Empty File Pool directory name (must be 'NNNk', where NNN is a number which 
> is a multiple of 4) (Partition: 1; EFP directory: '9k')
> May 4 18:55:00 somehostname kernel: qpidd[6240]: segfault at 10 ip 
> 7f4219af8e19 sp 7ffc227a6350 error 4 in 
> linearstore.so[7f4219ac4000+bd000]{noformat}
>  In the event that the random number _is_ divisible by 4, a randomly sized 
> directory containing no files may appear in the partition EFP.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core

2018-05-15 Thread Kim van der Riet (JIRA)


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

Kim van der Riet commented on QPID-8184:


Commit from Kim van der Riet with incorrect tag QPIDIT-8184 instead of 
QPID-8184:

QPIDIT-8184: Second part of fix: Change error handling for EFP exceptions such 
that the broker shuts down more cleanly without a spurious segfault. Also 
addeed tests to the linearstore test suite which forces such errors and checks 
that they are handles correctly. A minor update to brokertest.py fixes tests 
which use the EXPECT_EXIT_FAIL flag.

See: 
[https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=7a47046b5a24461c6acf3381147278749cadb745|https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=7a47046b5a24461c6acf3381147278749cadb745]

> [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error 
> followed by core
> 
>
> Key: QPID-8184
> URL: https://issues.apache.org/jira/browse/QPID-8184
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> Some users are experiencing difficulty recovering the store, especially when 
> there are a large  number of queues (several thousand). The log files show 
> the following pattern:
> {{JERR_EFP_BADEFPDIRNAME}} in which some arbitrary number which is not 
> divisible by 4 is being used as the EFP file size (called EFP directory in 
> the log), followed by a segfault:
> {noformat}
> May 4 18:55:00 somehostname qpidd[6240]: 2018-05-04 18:55:00 [Store] warning 
> Linear Store: EmptyFilePool create failed: jexception 0x0d03 
> EmptyFilePool::fileSizeKbFromDirName() threw JERR_EFP_BADEFPDIRNAME: Bad 
> Empty File Pool directory name (must be 'NNNk', where NNN is a number which 
> is a multiple of 4) (Partition: 1; EFP directory: '9k')
> May 4 18:55:00 somehostname kernel: qpidd[6240]: segfault at 10 ip 
> 7f4219af8e19 sp 7ffc227a6350 error 4 in 
> linearstore.so[7f4219ac4000+bd000]{noformat}
>  In the event that the random number _is_ divisible by 4, a randomly sized 
> directory containing no files may appear in the partition EFP.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8185) [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that client closes TCP connection on failure with sending connection.close and avoid spurious NPEs whilst awaiting channel closure

2018-05-15 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-8185:
-
Issue Type: Bug  (was: Improvement)

> [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that client closes TCP connection on 
> failure with sending connection.close and avoid spurious NPEs whilst awaiting 
> channel closure
> ---
>
> Key: QPID-8185
> URL: https://issues.apache.org/jira/browse/QPID-8185
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, 0.18, 0.20, 0.22, 0.24, 0.26, 0.28, 
> 0.30, 0.32, qpid-java-6.0.8, qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
> Attachments: 
> 0001-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Stop-handling-i.patch, 
> 0002-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Make-sure-that-.patch
>
>
> Sending connection.close as part of {{Connection#close}} can end-up in 
> timeout exception. The underlying TCP connection remains open and Broker can 
> continue sending data to the client when session close ends up in timeout as 
> well. The incoming frames cannot be associated with the sessions, as the 
> client removes session information on connection close. As result, a number 
> of confusing exceptions is reported.
> Here are the examples of exception stack-traces reported for the issue
> {noformat}
> INFO  Unsuspending channel threw an exception:
> [Thread-227][AMQSession.java:2374]
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely 
> fashion
> at 
> org.apache.qpid.client.util.BlockingWaiter.block(BlockingWaiter.java:170) 
> ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java:115)
>  ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:715)
>  ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:736)
>  ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:730)
>  ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQSession_0_8.sendSuspendChannel(AMQSession_0_8.java:728)
>  ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQSession.suspendChannel(AMQSession.java:3156) 
> [qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQSession.startDispatcherIfNecessary(AMQSession.java:2370)
>  [qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2223) 
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQSession.rollback(AMQSession.java:1881) 
> [qpid-client-0.32.jar:0.32]
> ERROR Error closing session: javax.jms.JMSException: Error closing session: 
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely 
> fashion [error code 408: Request 
> Timeout][DefaultMessageListenerContainer-2][AMQConnection.java:1039]
> ERROR Error closing connection
> 
> [DefaultMessageListenerContainer-2][AMQConnection.java:971]
> javax.jms.JMSException: Error closing session: 
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely 
> fashion [error code 408: Request Timeout]
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:764) 
> ~[qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:730) 
> ~[qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQConnection.closeAllSessions(AMQConnection.java:1035)
>  [qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:962) 
> [qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:951) 
> [qpid-client-0.32.jar:0.32]
> at 
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:951) 
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:935) 
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:916) 
> [qpid-client-0.32.jar:0.32]
> at 
> org.springframework.jms.connection.ConnectionFactoryUtils.releaseConnection(ConnectionFactoryUtils.java:80)
>  [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
> at 
>

[GitHub] qpid-proton issue #143: NO-JIRA: [c] link fuzzing binaries using CXX linker

2018-05-15 Thread codecov-io

Github user codecov-io commented on the issue:

https://github.com/apache/qpid-proton/pull/143
  
# [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/143?src=pr=h1) 
Report
> Merging 
[#143](https://codecov.io/gh/apache/qpid-proton/pull/143?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-proton/commit/1315f263823386f2a13767e16882d4da48329901?src=pr=desc)
 will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-proton/pull/143/graphs/tree.svg?token=UKKzV9XnFF=pr=650=150)](https://codecov.io/gh/apache/qpid-proton/pull/143?src=pr=tree)

```diff
@@   Coverage Diff   @@
##   master #143   +/-   ##
===
  Coverage   86.19%   86.19%   
===
  Files 236  236   
  Lines   3013730137   
===
  Hits2597825978   
  Misses   4159 4159
```



--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-proton/pull/143?src=pr=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Î = absolute  (impact)`, `Ã¸ = not affected`, `? = missing 
data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-proton/pull/143?src=pr=footer). 
Last update 
[1315f26...d33f6d3](https://codecov.io/gh/apache/qpid-proton/pull/143?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



---

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

[GitHub] qpid-proton pull request #143: NO-JIRA: [c] link fuzzing binaries using CXX ...

2018-05-15 Thread jdanekrh

GitHub user jdanekrh opened a pull request:

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

NO-JIRA: [c] link fuzzing binaries using CXX linker

This should allow for removal of patch file 
https://github.com/google/oss-fuzz/blob/1909d92b8bb068dd7aa94bdf22da4028ada385ea/projects/qpid-proton/c_tests_fuzz_CMakeLists.patch

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

$ git pull https://github.com/jdanekrh/qpid-proton jd_fuzz_cxx_link

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

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


commit d33f6d3892f75a893acf3073097767d91c843ba6
Author: Jiri Danek 
Date:   2018-05-15T10:36:49Z

NO-JIRA: [c] link fuzzing binaries using CXX linker




---

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

[jira] [Assigned] (QPID-8190) [JMS AMQP 0-x] Release Qpid JMS AMQP 0-x 6.3.1

2018-05-15 Thread Alex Rudyy (JIRA)


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

Alex Rudyy reassigned QPID-8190:


Assignee: Alex Rudyy

> [JMS AMQP 0-x] Release Qpid JMS AMQP 0-x 6.3.1
> --
>
> Key: QPID-8190
> URL: https://issues.apache.org/jira/browse/QPID-8190
> Project: Qpid
>  Issue Type: Task
>  Components: JMS AMQP 0-x
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> Defect release for the legacy client.
> https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message

2018-05-15 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-8139:
-
Description: 
When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
specifies a JMS message selectors including a {{JMSMessageID}} or 
{{JMSCorrelationID}} predicate, the selector can fail to find the target 
message in some circumstances.  This occurs when the message producer is 
configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
mode, {{BUILTIN}} the problem does not manifest.

The issue is the Broker-J JMS selector implementation does not understand the 
AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
Protocol (AMQP) JMS Mapping Version 1.0 [WD9].

The problem also manifests when the Broker's message conversion feature is in 
use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
following user list post:

http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html


  was:
(2018-05-10 - rewritten JIRA title/description)

When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
specifies a JMS message selectors including a {{JMSMessageID}} or 
{{JMSCorrelationID}} predicate, the selector can fail to find the target 
message in some circumstances.  This occurs when the message producer is 
configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
mode, {{BUILTIN}} the problem does not manifest.

The issue is the Broker-J JMS selector implementation does not understand the 
AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
Protocol (AMQP) JMS Mapping Version 1.0 [WD9].

The problem also manifests when the Broker's message conversion feature is in 
use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
following user list post:

http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html

(original text of JIRA preserved below)

JMS specification requires JMSMessageID value to start with prefix "ID:". The 
JMS client might add the prefix "ID:" to the values not starting from "ID:" in 
order to be JMS compliant. If the altered JMSMessageID value is used to build a 
selector expression like "JMSMEssageID='ID:'", the target message 
might not be found as Broker-J uses real message ids in message lookup.

Potentially, filtering functionality for JMSMEssageID expression can be 
enhanced to detect the cases when the "ID:" prefix is specified in the selector 
but not included into the real message id value and find the correct message.  


> [Broker-J] [AMQP1-0] [JMSBINDMAP]  JMS selectors using JMSMessageID or 
> JMSCorrelationID expressed using the AMQP type encoded form values fail to 
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Attachments: 
> 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch
>
>
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
> specifies a JMS message selectors including a {{JMSMessageID}} or 
> {{JMSCorrelationID}} predicate, the selector can fail to find the target 
> message in some circumstances.  This occurs when the message producer is 
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the 
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in 
> use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
> selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
> or

[jira] [Updated] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message

2018-05-15 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-8139:
-
Attachment: 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch

> [Broker-J] [AMQP1-0] [JMSBINDMAP]  JMS selectors using JMSMessageID or 
> JMSCorrelationID expressed using the AMQP type encoded form values fail to 
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Attachments: 
> 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch
>
>
> (2018-05-10 - rewritten JIRA title/description)
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
> specifies a JMS message selectors including a {{JMSMessageID}} or 
> {{JMSCorrelationID}} predicate, the selector can fail to find the target 
> message in some circumstances.  This occurs when the message producer is 
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the 
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in 
> use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
> selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
> or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html
> (original text of JIRA preserved below)
> JMS specification requires JMSMessageID value to start with prefix "ID:". The 
> JMS client might add the prefix "ID:" to the values not starting from "ID:" 
> in order to be JMS compliant. If the altered JMSMessageID value is used to 
> build a selector expression like "JMSMEssageID='ID:'", the target 
> message might not be found as Broker-J uses real message ids in message 
> lookup.
> Potentially, filtering functionality for JMSMEssageID expression can be 
> enhanced to detect the cases when the "ID:" prefix is specified in the 
> selector but not included into the real message id value and find the correct 
> message.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message

2018-05-15 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-8139:
-
Attachment: (was: 
0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch)

> [Broker-J] [AMQP1-0] [JMSBINDMAP]  JMS selectors using JMSMessageID or 
> JMSCorrelationID expressed using the AMQP type encoded form values fail to 
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> (2018-05-10 - rewritten JIRA title/description)
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
> specifies a JMS message selectors including a {{JMSMessageID}} or 
> {{JMSCorrelationID}} predicate, the selector can fail to find the target 
> message in some circumstances.  This occurs when the message producer is 
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the 
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in 
> use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
> selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
> or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html
> (original text of JIRA preserved below)
> JMS specification requires JMSMessageID value to start with prefix "ID:". The 
> JMS client might add the prefix "ID:" to the values not starting from "ID:" 
> in order to be JMS compliant. If the altered JMSMessageID value is used to 
> build a selector expression like "JMSMEssageID='ID:'", the target 
> message might not be found as Broker-J uses real message ids in message 
> lookup.
> Potentially, filtering functionality for JMSMEssageID expression can be 
> enhanced to detect the cases when the "ID:" prefix is specified in the 
> selector but not included into the real message id value and find the correct 
> message.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message

2018-05-15 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-8139:
-
Attachment: (was: 
0002-QPID-8139-Broker-J-AMQP-1.0-Summport-all-message-for.patch)

> [Broker-J] [AMQP1-0] [JMSBINDMAP]  JMS selectors using JMSMessageID or 
> JMSCorrelationID expressed using the AMQP type encoded form values fail to 
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> (2018-05-10 - rewritten JIRA title/description)
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
> specifies a JMS message selectors including a {{JMSMessageID}} or 
> {{JMSCorrelationID}} predicate, the selector can fail to find the target 
> message in some circumstances.  This occurs when the message producer is 
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the 
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in 
> use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
> selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
> or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html
> (original text of JIRA preserved below)
> JMS specification requires JMSMessageID value to start with prefix "ID:". The 
> JMS client might add the prefix "ID:" to the values not starting from "ID:" 
> in order to be JMS compliant. If the altered JMSMessageID value is used to 
> build a selector expression like "JMSMEssageID='ID:'", the target 
> message might not be found as Broker-J uses real message ids in message 
> lookup.
> Potentially, filtering functionality for JMSMEssageID expression can be 
> enhanced to detect the cases when the "ID:" prefix is specified in the 
> selector but not included into the real message id value and find the correct 
> message.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message

2018-05-15 Thread ASF subversion and git services (JIRA)


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

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

Commit f7d3ebbeb9a338b649664041136cb462768f0ea0 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=f7d3ebb ]

Revert "QPID-8139: [Broker-J][AMQP 1.0] Make sure that selector filter can 
handle JMSMessageID and JMSCorrelationID values with prefixes as defined in 
AMQP JMS mapping specification"

This reverts commit 86b31afbc98bbd980c2566d0fd48f72e30fe5c69.

Unintentional push of patch under review.


> [Broker-J] [AMQP1-0] [JMSBINDMAP]  JMS selectors using JMSMessageID or 
> JMSCorrelationID expressed using the AMQP type encoded form values fail to 
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Attachments: 
> 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch, 
> 0002-QPID-8139-Broker-J-AMQP-1.0-Summport-all-message-for.patch
>
>
> (2018-05-10 - rewritten JIRA title/description)
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
> specifies a JMS message selectors including a {{JMSMessageID}} or 
> {{JMSCorrelationID}} predicate, the selector can fail to find the target 
> message in some circumstances.  This occurs when the message producer is 
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the 
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in 
> use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
> selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
> or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html
> (original text of JIRA preserved below)
> JMS specification requires JMSMessageID value to start with prefix "ID:". The 
> JMS client might add the prefix "ID:" to the values not starting from "ID:" 
> in order to be JMS compliant. If the altered JMSMessageID value is used to 
> build a selector expression like "JMSMEssageID='ID:'", the target 
> message might not be found as Broker-J uses real message ids in message 
> lookup.
> Potentially, filtering functionality for JMSMEssageID expression can be 
> enhanced to detect the cases when the "ID:" prefix is specified in the 
> selector but not included into the real message id value and find the correct 
> message.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-8167:
--

Changes reviewed.  Documentation corrected.

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1
>
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8167:
-
Priority: Minor  (was: Major)

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1
>
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8167:
-
Fix Version/s: qpid-java-broker-7.1

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1
>
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

2018-05-15 Thread Keith Wall (JIRA)


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

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

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1
>
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message

2018-05-15 Thread ASF subversion and git services (JIRA)


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

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

Commit 86b31afbc98bbd980c2566d0fd48f72e30fe5c69 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=86b31af ]

QPID-8139: [Broker-J][AMQP 1.0] Make sure that selector filter can handle 
JMSMessageID and JMSCorrelationID values with prefixes as defined in AMQP JMS 
mapping specification


> [Broker-J] [AMQP1-0] [JMSBINDMAP]  JMS selectors using JMSMessageID or 
> JMSCorrelationID expressed using the AMQP type encoded form values fail to 
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Attachments: 
> 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch, 
> 0002-QPID-8139-Broker-J-AMQP-1.0-Summport-all-message-for.patch
>
>
> (2018-05-10 - rewritten JIRA title/description)
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer 
> specifies a JMS message selectors including a {{JMSMessageID}} or 
> {{JMSCorrelationID}} predicate, the selector can fail to find the target 
> message in some circumstances.  This occurs when the message producer is 
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}} 
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}.   In the default 
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the 
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing 
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in 
> use.   For instance, a message produced by a AMQP 0-10 producer cannot be 
> selected by an consumer using a Qpid JMS Client 1.0 using a  {{JMSMessageID}} 
> or {{JMSCorrelationID}} predicate.  This was originally highlighted by the 
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html
> (original text of JIRA preserved below)
> JMS specification requires JMSMessageID value to start with prefix "ID:". The 
> JMS client might add the prefix "ID:" to the values not starting from "ID:" 
> in order to be JMS compliant. If the altered JMSMessageID value is used to 
> build a selector expression like "JMSMEssageID='ID:'", the target 
> message might not be found as Broker-J uses real message ids in message 
> lookup.
> Potentially, filtering functionality for JMSMEssageID expression can be 
> enhanced to detect the cases when the "ID:" prefix is specified in the 
> selector but not included into the real message id value and find the correct 
> message.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

2018-05-15 Thread ASF subversion and git services (JIRA)


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

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

Commit 2d85f73e6704f3b69d40611fd6d52895067fc093 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2d85f73 ]

QPID-8167: [Broker-J] Fix documentation and the name of a constant.


> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8172:
-
Affects Version/s: qpid-java-6.0
   qpid-java-6.1

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, qpid-java-6.0, 
> qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8172:
-
Fix Version/s: qpid-java-broker-7.1.0

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (QPID-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-15 Thread Keith Wall (JIRA)


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

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

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8172) [Broker-J] OAuth2 authentication provider should not mandate setting of client secret

2018-05-15 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-8172:
--

Changes look reasonable to me.

> [Broker-J] OAuth2 authentication provider should not mandate setting of 
> client secret
> -
>
> Key: QPID-8172
> URL: https://issues.apache.org/jira/browse/QPID-8172
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
>
> The current implementation of OAuth2 authentication provider requires 
> specifying "client secret". However, the client secret can be an empty string 
> and can even be omitted in the request if it is empty. As per 
> [RFC6749|https://tools.ietf.org/html/rfc6749], section "2.3.1.  Client 
> Password":
> {quote}
> client_secret
>  REQUIRED.  The client secret.  The client MAY omit the
>  parameter if the client secret is an empty string.
> {quote}
> Thus, OAuth2 authentication provider should not mandate setting of client 
> secret.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

40 matches

Mail list logo