[jira] [Resolved] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bolz resolved QPIDJMS-373.
--
Resolution: Resolved
Fix Version/s: 0.32.0
Hi All,
Thanks for [~gemmellr] and [~rgodfrey] for the discussion around the issue and
[~tabish121] for implementing the new feature (in QPIDJMS-384).
For me the new feature enabled my use case ;o)
Kind regards, Michael
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
> Fix For: 0.32.0
>
>
> Add support for OAuth flow ("client_credentials" and "password") (-and
> setting of "Authorization" Header- moved into
> [QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) during
> WebSocket connection handshake.
> -Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).- (see above)
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
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] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bolz closed QPIDJMS-373.
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
> Fix For: 0.32.0
>
>
> Add support for OAuth flow ("client_credentials" and "password") (-and
> setting of "Authorization" Header- moved into
> [QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) during
> WebSocket connection handshake.
> -Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).- (see above)
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
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-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466940#comment-16466940
]
ASF subversion and git services commented on PROTON-1842:
-
Commit 0a5c18a1034deaa76deb9367d068e80c2726aa7c in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0a5c18a ]
PROTON-1842: timer rearm outside lock can try to access freed memory if another
thread ends the pconnection ahead of the rearm
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: helloworld.cpp
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
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-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466728#comment-16466728 ] ASF GitHub Bot commented on DISPATCH-927: - GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/301 DISPATCH-927 - System test for fix. Makes sure both detaches are echo… …ed back You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-927 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/301.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 #301 commit 7e4dfd7334ea994719e178cba78998c1933f60dc Author: Fernando Giorgetti Date: 2018-05-08T01:31:36Z DISPATCH-927 - System test for fix. Makes sure both detaches are echoed back > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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
[GitHub] qpid-dispatch pull request #301: DISPATCH-927 - System test for fix. Makes s...
GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/301 DISPATCH-927 - System test for fix. Makes sure both detaches are echo⦠â¦ed back You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-927 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/301.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 #301 commit 7e4dfd7334ea994719e178cba78998c1933f60dc Author: Fernando Giorgetti Date: 2018-05-08T01:31:36Z DISPATCH-927 - System test for fix. Makes sure both detaches are echoed back --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #300: DISPATCH-927 - System test for fix. Makes s...
Github user fgiorgetti closed the pull request at: https://github.com/apache/qpid-dispatch/pull/300 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466727#comment-16466727 ] ASF GitHub Bot commented on DISPATCH-927: - Github user fgiorgetti closed the pull request at: https://github.com/apache/qpid-dispatch/pull/300 > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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
[GitHub] qpid-dispatch pull request #300: DISPATCH-927 - System test for fix. Makes s...
GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/300 DISPATCH-927 - System test for fix. Makes sure both detaches are echo⦠â¦ed back You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-927 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/300.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 #300 commit 4a7cd80ab63c17b2801d0623a7f3f4244104720a Author: Fernando Giorgetti Date: 2018-05-08T01:31:36Z DISPATCH-927 - System test for fix. Makes sure both detaches are echoed back --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466722#comment-16466722 ] ASF GitHub Bot commented on DISPATCH-927: - GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/300 DISPATCH-927 - System test for fix. Makes sure both detaches are echo… …ed back You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-927 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/300.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 #300 commit 4a7cd80ab63c17b2801d0623a7f3f4244104720a Author: Fernando Giorgetti Date: 2018-05-08T01:31:36Z DISPATCH-927 - System test for fix. Makes sure both detaches are echoed back > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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-1831) [c] duplicate link names cause invalid read in pn_transport_unbind_handles
[ https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466602#comment-16466602 ] ASF GitHub Bot commented on PROTON-1831: Github user alanconway commented on the issue: https://github.com/apache/qpid-proton/pull/142 The commit makes things better than they were but is not the final fix, as per comments from you and Gordon. Closing the PR as the JIRA has the comments - I think they are valid, just haven't got back to it yet. > [c] duplicate link names cause invalid read in pn_transport_unbind_handles > -- > > Key: PROTON-1831 > URL: https://issues.apache.org/jira/browse/PROTON-1831 > Project: Qpid Proton > Issue Type: Bug >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > See PROTON-1832 for the detail, this JIRA was inadvertently spammed with > comments for it. -- 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
[GitHub] qpid-proton issue #142: PROTON-1831: Incorrect open/close sequence for same ...
Github user alanconway commented on the issue: https://github.com/apache/qpid-proton/pull/142 The commit makes things better than they were but is not the final fix, as per comments from you and Gordon. Closing the PR as the JIRA has the comments - I think they are valid, just haven't got back to it yet. --- - 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
[
https://issues.apache.org/jira/browse/QPID-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466470#comment-16466470
]
ASF subversion and git services commented on QPID-8184:
---
Commit 3a37ceed5faf667c6a0e45e023bb1d4fced66b75 in qpid-cpp's branch
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=3a37cee ]
QPID-8184: Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error
followed by core: Fix by Pavel Moravec
> [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 prodrhs1l 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 prodrhs1l 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
[
https://issues.apache.org/jira/browse/QPID-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466468#comment-16466468
]
Kim van der Riet commented on QPID-8184:
Pavel Moravec has discovered the root cause of this issue, see
[https://bugzilla.redhat.com/show_bug.cgi?id=1561819#c18.] It appears that when
using ::readlink(), the string containing the link destination is copied into
the supplied buffer, but without being terminated with a '\0'. In some cases,
there is remaining data in the buffer which when searched from the rear of the
string yields odd results.
The issue appears to be solved by simply terminating the string in the buffer
with a '\0'.
> [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 prodrhs1l 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 prodrhs1l 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-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core
[
https://issues.apache.org/jira/browse/QPID-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated QPID-8184:
---
Description:
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 prodrhs1l 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 prodrhs1l 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.
was:
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 prodrhs1l 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 prodrhs1l kernel: qpidd[6240]: segfault at 10 ip
7f4219af8e19 sp 7ffc227a6350 error 4 in
linearstore.so[7f4219ac4000+bd000]{noformat}
> [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 prodrhs1l 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 prodrhs1l 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-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core
[
https://issues.apache.org/jira/browse/QPID-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated QPID-8184:
---
Description:
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 prodrhs1l 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 prodrhs1l kernel: qpidd[6240]: segfault at 10 ip
7f4219af8e19 sp 7ffc227a6350 error 4 in
linearstore.so[7f4219ac4000+bd000]{noformat}
was:
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, followed by a segfault:
{noformat}
May 4 18:55:00 prodrhs1l 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 prodrhs1l kernel: qpidd[6240]: segfault at 10 ip
7f4219af8e19 sp 7ffc227a6350 error 4 in
linearstore.so[7f4219ac4000+bd000]{noformat}
> [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 prodrhs1l 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 prodrhs1l kernel: qpidd[6240]: segfault at 10 ip
> 7f4219af8e19 sp 7ffc227a6350 error 4 in
> linearstore.so[7f4219ac4000+bd000]{noformat}
>
--
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] [Created] (QPID-8184) [linearstore] Recovery intermittently produces JERR_EFP_BADEFPDIRNAME error followed by core
Kim van der Riet created QPID-8184:
--
Summary: [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
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, followed by a segfault:
{noformat}
May 4 18:55:00 prodrhs1l 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 prodrhs1l kernel: qpidd[6240]: segfault at 10 ip
7f4219af8e19 sp 7ffc227a6350 error 4 in
linearstore.so[7f4219ac4000+bd000]{noformat}
--
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-988) Documentation of policy default vhost is wrong
[ https://issues.apache.org/jira/browse/DISPATCH-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466297#comment-16466297 ] ASF subversion and git services commented on DISPATCH-988: -- Commit 945cac6fded031c0f47b93d620bf975ee38f089d in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=945cac6 ] DISPATCH-988: Fix description of how default vhost processing works > Documentation of policy default vhost is wrong > -- > > Key: DISPATCH-988 > URL: https://issues.apache.org/jira/browse/DISPATCH-988 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.0.1 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > The policy defaultVhost property is described incorrectly. it is enabled by > default and set to the vhost name _$default_. Default vhost processing is > disabled when 1) the defaultVhost property is set to blank or 2) when there > is no vhost whose hostname matches the defaultVhost setting. -- 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-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466277#comment-16466277 ] ASF GitHub Bot commented on DISPATCH-927: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/299 > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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
[GitHub] qpid-dispatch pull request #299: DISPATCH-927 - System test for fix. Makes s...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/299 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-988) Documentation of policy default vhost is wrong
Chuck Rolke created DISPATCH-988: Summary: Documentation of policy default vhost is wrong Key: DISPATCH-988 URL: https://issues.apache.org/jira/browse/DISPATCH-988 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.0.1 Reporter: Chuck Rolke Assignee: Chuck Rolke The policy defaultVhost property is described incorrectly. it is enabled by default and set to the vhost name _$default_. Default vhost processing is disabled when 1) the defaultVhost property is set to blank or 2) when there is no vhost whose hostname matches the defaultVhost setting. -- 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-7830) Heap dominated by duplicates of common routing values / header values etc
[
https://issues.apache.org/jira/browse/QPID-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466107#comment-16466107
]
ASF subversion and git services commented on QPID-7830:
---
Commit 5b6dfcd94ef64544040de53d38e2463d327ebcb1 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=5b6dfcd ]
QPID-7830: [Broker-J] Cache encoded and decoded values for 0-10 str8
> Heap dominated by duplicates of common routing values / header values etc
> -
>
> Key: QPID-7830
> URL: https://issues.apache.org/jira/browse/QPID-7830
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> When used for store and forwarding, in some use cases the Broker's heap can
> become dominated by duplicates of common values such as routing information
> (e.g. {{amq.direct}} or an application's queue name) or common header values
> (e.g a application/octet-stream or an application's user id).
> On the 0-8..0-91 paths, every enqueued message gets its own
> {{MessagePublishInfo}} referencing its own {{AMQShortString}} exchange and
> routing keys. For some use-cases, these are drawn from a small set. On the
> AMQP 1.0 path, {{Properties#to}} is an example. 0-10 is probably affected
> too.
> This unnecessarily increases the heap requirements of the Broker.
> The Broker should adopt a sensible intern/caching policy with the same policy
> applying regardless of whether messages follow the on-line enqueue or
> recovery path. Note that in AMQP 1.0, values which are {{Symbols}} have
> their underlying String automatically interned.
--
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-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465979#comment-16465979
]
ASF subversion and git services commented on QPID-8182:
---
Commit d293206d72989f1004f8fa3577f36d2da104f615 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=d293206 ]
QPID-8182: [End to End Conversion Tests] Extend test mechanism to allow testing
of JMS provider assigned message ids. Add test cases too.
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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-8183) [cpp] Remove deprecated code
[ https://issues.apache.org/jira/browse/QPID-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465954#comment-16465954 ] ASF subversion and git services commented on QPID-8183: --- Commit dfb1f43067d111e97f3ab0c09f87065c6e959c77 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=dfb1f43 ] QPID-8183: Remove examples for the deprecated QMF API > [cpp] Remove deprecated code > > > Key: QPID-8183 > URL: https://issues.apache.org/jira/browse/QPID-8183 > Project: Qpid > Issue Type: Task > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.38.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.39.0 > > -- 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-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465947#comment-16465947
]
Keith Wall commented on QPID-8182:
--
I find other similar problems:
When publishing with Qpid JMS Client with message id type {{UUID}} and
{{UuidStringMode}} modes and receiving the message with Qpid JMS Client 0-x
over AMQP 0-8..0-91, the received converted message arrives with a message id
short-string without the ID: prefix. In all other cases the client publishes
and receives AMQP 0-8..0-91 with an {{ID:}} prefix. These paths should be made
consistent.
When publishing with Qpid JMS Client 0-x over AMQP 0-8..0-91and receiving with
Qpid JMS Client, the received converted message arrives with a
{{message-id-string}} containing the {{ID:}} prefix following by the {{UUID}}
in stringified form. It would be preferable if a {{message-id-uuid}} were used
if possible. This would maximise compatibility with non-JMS clients (that know
nothing of the ID: prefix) and it more efficient on the wire.
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8182:
-
Fix Version/s: (was: qpid-java-broker-7.0.0)
qpid-java-broker-7.0.4
qpid-java-broker-7.1.0
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8182:
-
Affects Version/s: qpid-java-broker-7.0.0
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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] [Created] (QPID-8183) [cpp] Remove deprecated code
Justin Ross created QPID-8183: - Summary: [cpp] Remove deprecated code Key: QPID-8183 URL: https://issues.apache.org/jira/browse/QPID-8183 Project: Qpid Issue Type: Task Components: C++ Broker, C++ Client Affects Versions: qpid-cpp-1.38.0 Reporter: Justin Ross Assignee: Justin Ross Fix For: qpid-cpp-1.39.0 -- 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] Selector containing JMSMessageID expressions might not find the message when expression JMSMessageID value starts with 'ID:' prefix but the real message id does
[ https://issues.apache.org/jira/browse/QPID-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8139: - Description: 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. was: 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 compliment. 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] Selector containing JMSMessageID expressions might not find the > message when expression JMSMessageID value starts with 'ID:' prefix but the > real message id does not include the prefix > -- > > 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 >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 > > > 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] [Created] (QPID-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
Keith Wall created QPID-8182:
Summary: [Broker-J] [Conversion] Message id fidelity lost when
converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed
UUID
Key: QPID-8182
URL: https://issues.apache.org/jira/browse/QPID-8182
Project: Qpid
Issue Type: Bug
Components: Broker-J
Reporter: Keith Wall
Fix For: qpid-java-broker-7.0.0
If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the UUID
of the message id received does not match the original value generated by the
client.
--
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-7442) Deleting a virtualhost leaves itself and the children in the configuration store
[
https://issues.apache.org/jira/browse/QPID-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7442.
--
Resolution: Fixed
Closing old JIRA as changes have been released as part of 7.0
> Deleting a virtualhost leaves itself and the children in the configuration
> store
>
>
> Key: QPID-7442
> URL: https://issues.apache.org/jira/browse/QPID-7442
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> If I create a BDB virtualhostnode (for example) with a ProvidedStore, then
> delete the VH the configuration entries corresponding to the VH are left
> behind in the store.
> * If I immediately restart the Broker, the deleted VH reappears.
> * If I create a new virtualhost in its place (using REST), the creation is
> seemingly successful, but on restart the virtuallhostnode goes into ERROR
> state.
> {noformat}
> 2016-09-29 23:16:27,105 INFO [Broker-Config] (q.m.c.recovery_start) -
> [Broker] [vh(/mybdb)/ms(BDBConfigurationStore)] CFG-1004 : Recovery Start
> 2016-09-29 23:16:27,121 INFO [Broker-Config]
> (o.a.q.s.s.GenericStoreUpgrader) - VirtualHost store has model version 6.1.
> Number of record(s) 10
> 2016-09-29 23:16:27,126 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,129 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,133 ERROR [Broker-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'mybdb'. Object will be put into ERROR state.
> org.apache.qpid.server.model.AbstractConfiguredObject$DuplicateNameException:
> Child of type ProvidedStoreVirtualHostImplWithAccessChecking already exists
> with name of mybdb
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerChild(AbstractConfiguredObject.java:2129)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerWithParents(AbstractConfiguredObject.java:684)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:139)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:118)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:188)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> [classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.recover(VirtualHostStoreUpgraderAndRecoverer.java:615)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.upgradeAndRecover(VirtualHostStoreUpgraderAndRecoverer.java:594)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.activate(AbstractStandardVirtualHostNode.java:102)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:167)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_101]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_101]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_101]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_101]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> [classes/:na]
> at
> org.apache.qpid.server.mo
[jira] [Updated] (QPID-7442) Deleting a virtualhost leaves itself and the children in the configuration store
[
https://issues.apache.org/jira/browse/QPID-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7442:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
qpid-java-broker-7.0.0
> Deleting a virtualhost leaves itself and the children in the configuration
> store
>
>
> Key: QPID-7442
> URL: https://issues.apache.org/jira/browse/QPID-7442
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> If I create a BDB virtualhostnode (for example) with a ProvidedStore, then
> delete the VH the configuration entries corresponding to the VH are left
> behind in the store.
> * If I immediately restart the Broker, the deleted VH reappears.
> * If I create a new virtualhost in its place (using REST), the creation is
> seemingly successful, but on restart the virtuallhostnode goes into ERROR
> state.
> {noformat}
> 2016-09-29 23:16:27,105 INFO [Broker-Config] (q.m.c.recovery_start) -
> [Broker] [vh(/mybdb)/ms(BDBConfigurationStore)] CFG-1004 : Recovery Start
> 2016-09-29 23:16:27,121 INFO [Broker-Config]
> (o.a.q.s.s.GenericStoreUpgrader) - VirtualHost store has model version 6.1.
> Number of record(s) 10
> 2016-09-29 23:16:27,126 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,129 INFO [Broker-Config] (q.m.v.created) - [Broker]
> VHT-1001 : Created : mybdb
> 2016-09-29 23:16:27,133 ERROR [Broker-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'mybdb'. Object will be put into ERROR state.
> org.apache.qpid.server.model.AbstractConfiguredObject$DuplicateNameException:
> Child of type ProvidedStoreVirtualHostImplWithAccessChecking already exists
> with name of mybdb
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerChild(AbstractConfiguredObject.java:2129)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.registerWithParents(AbstractConfiguredObject.java:684)
> [classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:139)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:118)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:188)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> [classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> [classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.recover(VirtualHostStoreUpgraderAndRecoverer.java:615)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.upgradeAndRecover(VirtualHostStoreUpgraderAndRecoverer.java:594)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.activate(AbstractStandardVirtualHostNode.java:102)
> ~[classes/:na]
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:167)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_101]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_101]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_101]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_101]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> [classes/:na]
> at
> org.apache.qpid.s
[jira] [Resolved] (QPID-7557) Enhance model to expose meta-information about the current connection
[ https://issues.apache.org/jira/browse/QPID-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7557. -- Resolution: Fixed Fix Version/s: qpid-java-broker-7.0.0 Closing old JIRA as changes have been released as part of 7.0 > Enhance model to expose meta-information about the current connection > - > > Key: QPID-7557 > URL: https://issues.apache.org/jira/browse/QPID-7557 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.0 > > > VirtualHost model should be enhanced to allow a client to know information > about its *current* connection. It will be an analogue to the Broker#getUser > which returns information about the current user. The information should > include remore/local IP address and port, protools and transport.This > should work for both AMQP and HTTP connections. > For AMQP connections, the information returned should be be sufficient to > allow a client to find the Connection management object, if required. > A use case for this feature is test automation - specifically the performance > / interversion test frame that records details of the tested connection as > part of the results. -- 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-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port
[ https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8181: - Fix Version/s: qpid-java-broker-7.0.4 qpid-java-broker-7.1.0 > [Broker-J] Add statistics for a total number of connections established on > AMQP port > > > Key: QPID-8181 > URL: https://issues.apache.org/jira/browse/QPID-8181 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 > > > A statistics for a current number of connections is available on AMQP port. > Introduction of additional statistic for a total number of connections > established on AMQP port would allow to detect such use cases as "connection > per message anti-pattern" without even looking into Qpid broker logs. -- 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-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port
[ https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465702#comment-16465702 ] ASF subversion and git services commented on QPID-8181: --- Commit 8ea3b655f026a02d7548a2abaadde471e6195dcf in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8ea3b65 ] QPID-8181: [Broker-J] Add statistics for a total number of connections established on AMQP port (cherry picked from commit e84273b056abc9a38ec635c52cacbd19d0b45a99) > [Broker-J] Add statistics for a total number of connections established on > AMQP port > > > Key: QPID-8181 > URL: https://issues.apache.org/jira/browse/QPID-8181 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Priority: Minor > > A statistics for a current number of connections is available on AMQP port. > Introduction of additional statistic for a total number of connections > established on AMQP port would allow to detect such use cases as "connection > per message anti-pattern" without even looking into Qpid broker logs. -- 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-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port
[ https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8181: - Priority: Minor (was: Major) > [Broker-J] Add statistics for a total number of connections established on > AMQP port > > > Key: QPID-8181 > URL: https://issues.apache.org/jira/browse/QPID-8181 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Priority: Minor > > A statistics for a current number of connections is available on AMQP port. > Introduction of additional statistic for a total number of connections > established on AMQP port would allow to detect such use cases as "connection > per message anti-pattern" without even looking into Qpid broker logs. -- 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-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port
[ https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465647#comment-16465647 ] Keith Wall commented on QPID-8181: -- Changes look reasonable to me. > [Broker-J] Add statistics for a total number of connections established on > AMQP port > > > Key: QPID-8181 > URL: https://issues.apache.org/jira/browse/QPID-8181 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Priority: Major > > A statistics for a current number of connections is available on AMQP port. > Introduction of additional statistic for a total number of connections > established on AMQP port would allow to detect such use cases as "connection > per message anti-pattern" without even looking into Qpid broker logs. -- 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
