Re: delete message from Queue through Java code
For example, I have 10 messages read from Queue, and 4th and 6th messages are not delivered. Then ultimately except 4th and 6th messages all other messages to be removed from the Queue. Now, In my code 1. How can I differentiate the acknowledge for each message. 2. Is it sequential that I will get the ack in the same order in the Queue ? Queue Message:1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Ack:ack1, ack2, ack3, negack4, ack5, negack6, ack7, ack8, ack9, ack10 3. I think it will not be sequential (priority queue), how should I hold the ack for perticular message and process other messages ? -- View this message in context: http://qpid.2158936.n2.nabble.com/Re-delete-message-from-Queue-through-Java-code-tp7663338p7663397.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-522) Apache Qpid Proton on Mac/OSX - C/Objective-C
[ https://issues.apache.org/jira/browse/PROTON-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16024041#comment-16024041 ] ivy commented on PROTON-522: I've seen lots of discussion about ppl getting this to work and issues closed around it, Is there anywhere we can find documentation on this, even if it is informal? Thanks in advance. > Apache Qpid Proton on Mac/OSX - C/Objective-C > - > > Key: PROTON-522 > URL: https://issues.apache.org/jira/browse/PROTON-522 > Project: Qpid Proton > Issue Type: New Feature >Reporter: Guy Dillen > Labels: close-pending, osx > > I would like using Apache Qpid Proton-C from a C or Objective-C application > on Mac/OSX to connect as a client to Windows Azure Service Bus. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023533#comment-16023533
]
ASF subversion and git services commented on PROTON-1288:
-
Commit 860b32291fa31c343cc3dad63524a36ce9082a9c in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=860b322 ]
PROTON-1288: allocate extra storage with pn_message for internal use
Allow extra space to be allocated in the same block used by pn_message_t
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-1288.
-
Resolution: Fixed
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023535#comment-16023535
]
ASF subversion and git services commented on PROTON-1288:
-
Commit f2df847b552685f80429715832e55207d68bbbcb in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2df847 ]
PROTON-1288: c++ reinstate engine_test as connection_driver_test
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023537#comment-16023537
]
ASF subversion and git services commented on PROTON-1288:
-
Commit 16147e9318a90d8411ee3758418ff60d2dcb8356 in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=16147e9 ]
PROTON-1288: c++ documentation for maps and type conversions
Also filled in some missing doxygen markers for header files.
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023536#comment-16023536
]
ASF subversion and git services commented on PROTON-1288:
-
Commit 864519ddca6c45a10ec01598b3ff3b33e5591561 in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=864519d ]
PROTON-1288: c++ provide convenient access to message/filter maps
proton::map type to wrap map values for message properties/annotations and
source filters.
Has the following features:
- type safe template for the standard AMQP 'restricted map' types
- simple get()/put() interface for simple check/set individual properties
- converts directly to/from a proton::value efficient pass-through, no re-coding
- converts directly to/from std:map, std::unordered_map etc.
- encode/decode only as required
Intended use: use proton::map directly for simple get()/put(), convert to a
standard map or sequence type for more complex use (iteration, preserving
encoded order etc.)
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023532#comment-16023532
]
ASF subversion and git services commented on PROTON-1288:
-
Commit d588798b719d6c724958d456d24e7e354351386f in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d588798 ]
PROTON-1288: remove un-necessary internal::value_ref class.
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value
[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023534#comment-16023534
]
ASF subversion and git services commented on PROTON-1288:
-
Commit 48a5e47a09268ddb19f925d8f66301718f42b87a in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=48a5e47 ]
PROTON-1288: c++ hide proton::message implementation details
Hide extra book-keeping types in extra storage allocated with the pn_message_t.
> c++ provide access to message maps as proton::value
> ---
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.14.0, 0.15.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7731) Upgrade to Jetty 9.4
[ https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023473#comment-16023473 ] Alex Rudyy commented on QPID-7731: -- I raise issue [https://github.com/eclipse/jetty.project/issues/1569] on github about current restriction in WebSocketProvider#setMaxBinaryMessageSize() disallowing setting of maxBinaryMessageSize to 0 > Upgrade to Jetty 9.4 > > > Key: QPID-7731 > URL: https://issues.apache.org/jira/browse/QPID-7731 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch > > > The version of Jetty used by the Java Broker is v8.1. This is now marked as > EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an > option now we are on Java 8). The Jetty API has changed substantially so > the HTTP Management is probably going to need a deep rewrite. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7731) Upgrade to Jetty 9.4
[ https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7731: - Status: Reviewable (was: In Progress) > Upgrade to Jetty 9.4 > > > Key: QPID-7731 > URL: https://issues.apache.org/jira/browse/QPID-7731 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch > > > The version of Jetty used by the Java Broker is v8.1. This is now marked as > EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an > option now we are on Java 8). The Jetty API has changed substantially so > the HTTP Management is probably going to need a deep rewrite. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1481) Improve the capability to inject work into serialised contexts
[ https://issues.apache.org/jira/browse/PROTON-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1481: Fix Version/s: 0.18.0 > Improve the capability to inject work into serialised contexts > -- > > Key: PROTON-1481 > URL: https://issues.apache.org/jira/browse/PROTON-1481 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1339) Event_loop injection is very slow to trigger the events
[
https://issues.apache.org/jira/browse/PROTON-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-1339:
Fix Version/s: 0.18.0
> Event_loop injection is very slow to trigger the events
> ---
>
> Key: PROTON-1339
> URL: https://issues.apache.org/jira/browse/PROTON-1339
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Adel Boutros
>Assignee: Andrew Stitcher
> Labels: reproducer
> Fix For: 0.18.0
>
> Attachments: main.cpp
>
>
> Full details here:
> http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-0-15-0-Event-loop-injection-is-very-slow-compared-to-timer-schedule-td7652982.html
> The attached test code requires a Broker running.
> Output of attached code:
> {code}
> functor called
> closed connection took 1.155 seconds
> {code}
> ==> 1.155 seconds is too much
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1381) Compiler errors: dereferencing pointer to incomplete type DH {aka struct dh_st}
[
https://issues.apache.org/jira/browse/PROTON-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-1381:
Fix Version/s: 0.18.0
> Compiler errors: dereferencing pointer to incomplete type DH {aka struct
> dh_st}
> ---
>
> Key: PROTON-1381
> URL: https://issues.apache.org/jira/browse/PROTON-1381
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.14.0, 0.16.0
> Environment: GCC 6.2.1, OpenSSL 1.1.0c
>Reporter: Volker Diels-Grabsch
>Assignee: Andrew Stitcher
>Priority: Blocker
> Labels: build, patch
> Fix For: 0.18.0
>
> Attachments:
> qpid-proton-0.14.0-fix-dereferencing-pointer-to-incomplete-type.patch
>
>
> Proton-C doesn't build with GCC 6.2.1 and OpenSSL 1.1.0c. The error message
> is:
> {code:borderStyle=solid}
> [ 51%] Building C object
> proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o
> /.../proton-c/src/ssl/openssl.c: In function ‘get_dh2048’:
> /.../proton-c/src/ssl/openssl.c:406:5: error: dereferencing pointer to
> incomplete type ‘DH {aka struct dh_st}’
>dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
> ^~
> proton-c/CMakeFiles/qpid-proton.dir/build.make:1102: recipe for target
> 'proton-c/CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o' failed
> {code}
> The attached patch fixes this issue for 0.14.0 and also works for 0.16.0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1482) Add capability to schedule work to happen later on work queues
[ https://issues.apache.org/jira/browse/PROTON-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1482: Fix Version/s: 0.18.0 > Add capability to schedule work to happen later on work queues > -- > > Key: PROTON-1482 > URL: https://issues.apache.org/jira/browse/PROTON-1482 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7731) Upgrade to Jetty 9.4
[ https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023161#comment-16023161 ] ASF subversion and git services commented on QPID-7731: --- Commit c5e8ab2ce813cc1f28333fc2ea748569c992ec71 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=c5e8ab2 ] QPID-7731: Address remaining jetty upgrade issues * Address review comments from Keith Wall * Change Apache CI configuration settings to avoid exceeding the maximum thread limit for http port in system tests > Upgrade to Jetty 9.4 > > > Key: QPID-7731 > URL: https://issues.apache.org/jira/browse/QPID-7731 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, > 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch > > > The version of Jetty used by the Java Broker is v8.1. This is now marked as > EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an > option now we are on Java 8). The Jetty API has changed substantially so > the HTTP Management is probably going to need a deep rewrite. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1483) proactor/epoll.c:181: ptimer_callback: Assertion
[
https://issues.apache.org/jira/browse/PROTON-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1483.
--
Resolution: Fixed
Assignee: Cliff Jansen
Fix Version/s: 0.18.0
Required changing method to track expected callbacks for expired timers.
Abandoned strict accounting for looser "in doubt" transitions.
> proactor/epoll.c:181: ptimer_callback: Assertion
>
>
> Key: PROTON-1483
> URL: https://issues.apache.org/jira/browse/PROTON-1483
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.18.0
> Environment: Fedora 25
> Master source builds of qpid-proton and qpid-dispatch
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
> Fix For: 0.18.0
>
> Attachments: A.conf, B.conf
>
>
> Start a dispatch router network of two routers. Send client traffic or not.
> Let it sit for a few minutes.
> {noformat}
> qdrouterd: /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181:
> ptimer_callback: Assertion `exp_count >= pt->skip_count' failed.
> {noformat}
> Either router A or B may fail this way. Looking at one core dump the
> internals show:
> {noformat}
> (gdb) list
> 176 ssize_t l = read(pt->timerfd, &u_exp_count, sizeof(uint64_t));
> 177 (void)l; /* Silence compiler complaints in release build */
> 178 assert(l == sizeof(uint64_t));
> 179 assert(u_exp_count < INT_MAX); // or test and log it?
> 180 int exp_count = (int) u_exp_count;
> 181 assert(exp_count >= pt->skip_count);
> 182 assert(exp_count <= pt->pending_count);
> 183 exp_count -= pt->skip_count;
> 184 pt->skip_count = 0;
> 185 pt->pending_count -= exp_count;
> (gdb) p exp_count
> $1 = 1
> (gdb) p pt->skip_count
> $2 = 2
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> #1 0x7fc51c49d51a in __GI_abort () at abort.c:89
> #2 0x7fc51c493da7 in __assert_fail_base (fmt=,
> assertion=assertion@entry=0x7fc51d45fbc2 "exp_count >= pt->skip_count",
> file=file@entry=0x7fc51d45fb30
> "/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c",
> line=line@entry=181,
> function=function@entry=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041>
> "ptimer_callback") at assert.c:92
> #3 0x7fc51c493e52 in __GI___assert_fail (assertion=0x7fc51d45fbc2
> "exp_count >= pt->skip_count", file=0x7fc51d45fb30
> "/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c", line=181,
> function=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041> "ptimer_callback") at
> assert.c:101
> #4 0x7fc51d45b620 in ptimer_callback (pt=0xfd8db8) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181
> #5 0x7fc51d45ebae in proactor_process (p=0xfd8d40, timeout=true) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1537
> #6 0x7fc51d45f0ae in proactor_do_epoll (p=0xfd8d40, can_block=true) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1657
> #7 0x7fc51d45f196 in pn_proactor_wait (p=0xfd8d40) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1680
> #8 0x7fc51d901d6a in thread_run (arg=0xfcfdd0) at
> /home/chug/git/qpid-dispatch/src/server.c:817
> #9 0x7fc51d2416ca in start_thread (arg=0x7fc50fd93700) at
> pthread_create.c:333
> #10 0x7fc51c56df7f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
> {noformat}
> The attached conf files are for the test routers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1483) proactor/epoll.c:181: ptimer_callback: Assertion
[
https://issues.apache.org/jira/browse/PROTON-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023050#comment-16023050
]
ASF subversion and git services commented on PROTON-1483:
-
Commit a4e5c84d88eb32a1951e058836e5f509749a955b in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a4e5c84 ]
PROTON-1483: C epoll proactor, change timerfd accounting
> proactor/epoll.c:181: ptimer_callback: Assertion
>
>
> Key: PROTON-1483
> URL: https://issues.apache.org/jira/browse/PROTON-1483
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.18.0
> Environment: Fedora 25
> Master source builds of qpid-proton and qpid-dispatch
>Reporter: Chuck Rolke
> Attachments: A.conf, B.conf
>
>
> Start a dispatch router network of two routers. Send client traffic or not.
> Let it sit for a few minutes.
> {noformat}
> qdrouterd: /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181:
> ptimer_callback: Assertion `exp_count >= pt->skip_count' failed.
> {noformat}
> Either router A or B may fail this way. Looking at one core dump the
> internals show:
> {noformat}
> (gdb) list
> 176 ssize_t l = read(pt->timerfd, &u_exp_count, sizeof(uint64_t));
> 177 (void)l; /* Silence compiler complaints in release build */
> 178 assert(l == sizeof(uint64_t));
> 179 assert(u_exp_count < INT_MAX); // or test and log it?
> 180 int exp_count = (int) u_exp_count;
> 181 assert(exp_count >= pt->skip_count);
> 182 assert(exp_count <= pt->pending_count);
> 183 exp_count -= pt->skip_count;
> 184 pt->skip_count = 0;
> 185 pt->pending_count -= exp_count;
> (gdb) p exp_count
> $1 = 1
> (gdb) p pt->skip_count
> $2 = 2
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> #1 0x7fc51c49d51a in __GI_abort () at abort.c:89
> #2 0x7fc51c493da7 in __assert_fail_base (fmt=,
> assertion=assertion@entry=0x7fc51d45fbc2 "exp_count >= pt->skip_count",
> file=file@entry=0x7fc51d45fb30
> "/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c",
> line=line@entry=181,
> function=function@entry=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041>
> "ptimer_callback") at assert.c:92
> #3 0x7fc51c493e52 in __GI___assert_fail (assertion=0x7fc51d45fbc2
> "exp_count >= pt->skip_count", file=0x7fc51d45fb30
> "/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c", line=181,
> function=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041> "ptimer_callback") at
> assert.c:101
> #4 0x7fc51d45b620 in ptimer_callback (pt=0xfd8db8) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181
> #5 0x7fc51d45ebae in proactor_process (p=0xfd8d40, timeout=true) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1537
> #6 0x7fc51d45f0ae in proactor_do_epoll (p=0xfd8d40, can_block=true) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1657
> #7 0x7fc51d45f196 in pn_proactor_wait (p=0xfd8d40) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1680
> #8 0x7fc51d901d6a in thread_run (arg=0xfcfdd0) at
> /home/chug/git/qpid-dispatch/src/server.c:817
> #9 0x7fc51d2416ca in start_thread (arg=0x7fc50fd93700) at
> pthread_create.c:333
> #10 0x7fc51c56df7f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
> {noformat}
> The attached conf files are for the test routers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7756) Website updates Q2 2017
[ https://issues.apache.org/jira/browse/QPID-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023039#comment-16023039 ] ASF subversion and git services commented on QPID-7756: --- Commit 6ef38e82047d0201e49ff23999b0ea3716baf5a3 in qpid-cpp's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=6ef38e8 ] QPID-7756: remove stale introduction that we link past anyway > Website updates Q2 2017 > --- > > Key: QPID-7756 > URL: https://issues.apache.org/jira/browse/QPID-7756 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Justin Ross >Assignee: Justin Ross > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7756) Website updates Q2 2017
[ https://issues.apache.org/jira/browse/QPID-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023037#comment-16023037 ] ASF subversion and git services commented on QPID-7756: --- Commit 753d03c1dca2461bbbf01300c4c00759fff5470b in qpid-cpp's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=753d03c ] QPID-7756: remove stale WCF related content, the WCF binding is no longer > Website updates Q2 2017 > --- > > Key: QPID-7756 > URL: https://issues.apache.org/jira/browse/QPID-7756 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Justin Ross >Assignee: Justin Ross > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
[ https://issues.apache.org/jira/browse/QPID-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023036#comment-16023036 ] ASF subversion and git services commented on QPID-7265: --- Commit 57cbe59b5a46a620553d28306b0da648a1272895 in qpid-cpp's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=57cbe59 ] QPID-7756: remove stale AMQP 0-10 JMS client content, a seperate book for that client was based on it via QPID-7265 > migrate the AMQP 0-10 JMS client docs out of the old combined doc book. > --- > > Key: QPID-7265 > URL: https://issues.apache.org/jira/browse/QPID-7265 > Project: Qpid > Issue Type: Task > Components: Java Documentation >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: qpid-java-6.0.3 > > > Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since > 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its > because they are still part of the old 'Programming in Apache Qpid' book > along combined with the other older client docs. > Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 > client docs the qpid-java tree is challenging as there are a lot of areas the > two protocols differ in behaviour (which is the reason the two books exist). > As per suggestion at \[1\], the quick and easy thing for now is to just pull > the JMS bits out of the 'programming' guide and migrate those into the > qpid-java tree, remainingg as a seperate book. This at least allows them to > be published with each new release and be updated if actually needed. > Further consolidation and improvement can be done later as desired/time > allows. > \[1\] > http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7756) Website updates Q2 2017
[ https://issues.apache.org/jira/browse/QPID-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023035#comment-16023035 ] ASF subversion and git services commented on QPID-7756: --- Commit 57cbe59b5a46a620553d28306b0da648a1272895 in qpid-cpp's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=57cbe59 ] QPID-7756: remove stale AMQP 0-10 JMS client content, a seperate book for that client was based on it via QPID-7265 > Website updates Q2 2017 > --- > > Key: QPID-7756 > URL: https://issues.apache.org/jira/browse/QPID-7756 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Justin Ross >Assignee: Justin Ross > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7756) Website updates Q2 2017
[ https://issues.apache.org/jira/browse/QPID-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023040#comment-16023040 ] ASF subversion and git services commented on QPID-7756: --- Commit 99dd7d3874fdad4a853cdea5a8535a0d2e6491b3 in qpid-cpp's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=99dd7d3 ] QPID-7756: rename the book to better reflect its content > Website updates Q2 2017 > --- > > Key: QPID-7756 > URL: https://issues.apache.org/jira/browse/QPID-7756 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Justin Ross >Assignee: Justin Ross > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7756) Website updates Q2 2017
[ https://issues.apache.org/jira/browse/QPID-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023041#comment-16023041 ] ASF subversion and git services commented on QPID-7756: --- Commit e7ab5476c81ed393aa8c24b7f2422afe4306ba28 in qpid-cpp's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=e7ab547 ] QPID-7756: give the chapter an ID to control its output filename > Website updates Q2 2017 > --- > > Key: QPID-7756 > URL: https://issues.apache.org/jira/browse/QPID-7756 > Project: Qpid > Issue Type: Task > Components: Website >Reporter: Justin Ross >Assignee: Justin Ross > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7689) [Java Broker] Consider message header size where appropriate
[ https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022935#comment-16022935 ] ASF subversion and git services commented on QPID-7689: --- Commit d688b4ca6277f59d95828ca9a05db00c48b3da14 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d688b4c ] QPID-7689: [Java Broker] Consider message header size where appropriate > [Java Broker] Consider message header size where appropriate > > > Key: QPID-7689 > URL: https://issues.apache.org/jira/browse/QPID-7689 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The changes introduced by QPID-7618 have the broker track the size of each > queue including header.The new ring queue policy and producer flow > control now consider messages sizes including header. The queue depth > alerting and flow to disk ought to be consistent. > Is there actually value tracking queue size and queue size including header > separately? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7689) [Java Broker] Consider message header size where appropriate
[ https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022647#comment-16022647 ] Lorenz Quack edited comment on QPID-7689 at 5/24/17 1:54 PM: - The scope of this JIRA has been expanded (and the title adjusted to reflect this). Places that currently use message size without headers that should also consider the header size are: * Queue depth alerting * Message based queue alerting * QueueStatistics: en-/dequeued, persistent, unacked, and available * Consumer: unacknowledged and delivered stats * Exchange: routed, dropped, and received stats * -Connection: received, delivered- (see below) MessageInfo currently only exposes the message size without header. It should also expose the size of the header. CreditManagers will continue to use only the size of the message body without the header. was (Author: lorenz.quack): The scope of this JIRA has been expanded (and the title adjusted to reflect this). Places that currently use message size without headers that should also consider the header size are: * Queue depth alerting * Message based queue alerting * QueueStatistics: en-/dequeued, persistent, unacked, and available * Consumer: unacknowledged and delivered stats * Exchange: routed, dropped, and received stats * -Connection: received, delivered- see below MessageInfo currently only exposes the message size without header. It should also expose the size of the header. CreditManagers will continue to use only the size of the message body without the header. > [Java Broker] Consider message header size where appropriate > > > Key: QPID-7689 > URL: https://issues.apache.org/jira/browse/QPID-7689 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The changes introduced by QPID-7618 have the broker track the size of each > queue including header.The new ring queue policy and producer flow > control now consider messages sizes including header. The queue depth > alerting and flow to disk ought to be consistent. > Is there actually value tracking queue size and queue size including header > separately? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7689) [Java Broker] Consider message header size where appropriate
[ https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022647#comment-16022647 ] Lorenz Quack edited comment on QPID-7689 at 5/24/17 1:53 PM: - The scope of this JIRA has been expanded (and the title adjusted to reflect this). Places that currently use message size without headers that should also consider the header size are: * Queue depth alerting * Message based queue alerting * QueueStatistics: en-/dequeued, persistent, unacked, and available * Consumer: unacknowledged and delivered stats * Exchange: routed, dropped, and received stats * -Connection: received, delivered- see below MessageInfo currently only exposes the message size without header. It should also expose the size of the header. CreditManagers will continue to use only the size of the message body without the header. was (Author: lorenz.quack): The scope of this JIRA has been expanded (and the title adjusted to reflect this). Places that currently use message size without headers that should also consider the header size are: * Queue depth alerting * Message based queue alerting * QueueStatistics: en-/dequeued, persistent, unacked, and available * Consumer: unacknowledged and delivered stats * Exchange: routed, dropped, and received stats * Connection: received, delivered MessageInfo currently only exposes the message size without header. It should also expose the size of the header. CreditManagers will continue to use only the size of the message body without the header. > [Java Broker] Consider message header size where appropriate > > > Key: QPID-7689 > URL: https://issues.apache.org/jira/browse/QPID-7689 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The changes introduced by QPID-7618 have the broker track the size of each > queue including header.The new ring queue policy and producer flow > control now consider messages sizes including header. The queue depth > alerting and flow to disk ought to be consistent. > Is there actually value tracking queue size and queue size including header > separately? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7689) [Java Broker] Consider message header size where appropriate
[
https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022923#comment-16022923
]
Lorenz Quack commented on QPID-7689:
Connections have stats {{bytesIn}} and {{bytesOut}} that currently record the
message content (without headers) sizes coming in/out on that connection.
The name suggests it would be the amount of bytes regardless of nature of the
bytes (content, header, TLS overhead, ...) going over the connection.
Changing this is out of scope for this JIRA. Therefore, the old behaviour
(message content without headers) is kept.
> [Java Broker] Consider message header size where appropriate
>
>
> Key: QPID-7689
> URL: https://issues.apache.org/jira/browse/QPID-7689
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The changes introduced by QPID-7618 have the broker track the size of each
> queue including header.The new ring queue policy and producer flow
> control now consider messages sizes including header. The queue depth
> alerting and flow to disk ought to be consistent.
> Is there actually value tracking queue size and queue size including header
> separately?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-209. Resolution: Fixed Fix Version/s: 1.0.0 > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > Fix For: 1.0.0 > > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022908#comment-16022908 ] ASF GitHub Bot commented on DISPATCH-209: - Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/163 > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #163: DISPATCH-209 -- three-router test #3 dynami...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/163 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.
[ https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022907#comment-16022907 ] ASF subversion and git services commented on DISPATCH-209: -- Commit 5fd599d4df3e0dfef377419636e5fffe9537b296 in qpid-dispatch's branch refs/heads/master from [~mgoulish] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5fd599d ] DISPATCH-209 -- three-router test #3 dynamic reply-to. This closes #163 (cherry picked from commit b66a5c7620409252287ae2e3993a17c56758beae) > Three+ router test is needed in the system test suite. > -- > > Key: DISPATCH-209 > URL: https://issues.apache.org/jira/browse/DISPATCH-209 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Reporter: Ted Ross >Assignee: michael goulish > > There have arisen some issues that would have been caught had there been a > three-router test in the regression suite. This test should be added. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7595) [C++ Windows] CMake required version is too low for installation
[
https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reassigned QPID-7595:
Assignee: Chuck Rolke
Affects Version/s: (was: qpid-cpp-1.35.0)
qpid-cpp-1.36.0
Fix Version/s: (was: qpid-cpp-1.36.0)
qpid-cpp-1.37.0
Bumping affects+fix versions since the change was made after 1.36.0 was already
released.
> [C++ Windows] CMake required version is too low for installation
>
>
> Key: QPID-7595
> URL: https://issues.apache.org/jira/browse/QPID-7595
> Project: Qpid
> Issue Type: Bug
> Components: C++ Build
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: qpid-cpp-1.37.0
>
>
> The top level cmake lists declares
> {noformat}
> cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR)
> {noformat}
> But the installation in src/msvc.cmake on Windows uses
> {noformat}
> $
> {noformat}
>
> which was introduced in CMake 3.1.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-779) Credit is not issued for multicast address when no receiver is connected
[ https://issues.apache.org/jira/browse/DISPATCH-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-779: -- Fix Version/s: 1.0.0 > Credit is not issued for multicast address when no receiver is connected > > > Key: DISPATCH-779 > URL: https://issues.apache.org/jira/browse/DISPATCH-779 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Jakub Scholz > Fix For: 1.0.0 > > Attachments: dispatch.log, producer.log, qdrouterd.conf, receiver.log > > > When I configure a multicast address in the Dispatch router, I expect that my > producer should be able to send the multicasts even when no receiver is > connected (i.e. the messages will be dropped). However, it seems that > Dispatch will not issue any credit to the producer unless there is some > receiver already connected and the producer is therefore stuck waiting for > the credit. > Attached are the logs from both Dispatch as well as producer / receiver. I > attached also the router configuration file. It seems that the same problem > appears also after the receiver disconnects. The producer can still use the > remaining credit which was issued before, but the credit is not refreshed. > This problem seems to be both with 0.8.0 as well as with the latest master. > (the relateddiscussion on the mailing list: > http://qpid.2158936.n2.nabble.com/Credit-handling-for-sending-messages-to-multicast-addresses-in-Dispatch-td7663263.html) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: delete message from Queue through Java code
On 24 May 2017 at 11:57, girishlc wrote: > Rob, > > 1. When you talk about Queue Browsing, is it QueueBrowser class you are > talking ? > Yes > 2. I'm using Qpid Broker for Java with its in-built web console, where I > can > see the message status "Available" to "Acquired" after reading the message > from Client. > 3. I am receiving the acknowledgment from the consumer, able to send that > acknowledgment to Qpid. From that Qpid is able to remove the message but > there is no mapping between the messages acknowledged and removed. I want > to > map the acknowledgment based on the MessagID. Is there any method to get > the > messageID for the delivered message. > > The behaviour of acknowledge is defined by JMS, it is not specific to Qpid. From https://docs.oracle.com/javaee/7/api/javax/jms/Message.html#acknowledge-- : "Acknowledges all consumed messages of the session of this consumed message. All consumed JMS messages support the acknowledge method for use when a client has specified that its JMS session's consumed messages are to be explicitly acknowledged. By invoking acknowledge on a consumed message, a client acknowledges all messages consumed by the session that the message was delivered to." I think everyone agrees it would be a lot less confusing if the acknowledge() method was on the Session object (since it really operates against the whole Session, not the particular message you call it on). Unfortunately JMS defines the behaviour and places the method on the Message. JMS does not define a mechanism to acknowledge individual messages. -- Rob > --girish > > > > -- > View this message in context: http://qpid.2158936.n2.nabble. > com/Re-delete-message-from-Queue-through-Java-code-tp7663338p7663354.html > Sent from the Apache Qpid developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
Re: delete message from Queue through Java code
Rob, 1. When you talk about Queue Browsing, is it QueueBrowser class you are talking ? 2. I'm using Qpid Broker for Java with its in-built web console, where I can see the message status "Available" to "Acquired" after reading the message from Client. 3. I am receiving the acknowledgment from the consumer, able to send that acknowledgment to Qpid. From that Qpid is able to remove the message but there is no mapping between the messages acknowledged and removed. I want to map the acknowledgment based on the MessagID. Is there any method to get the messageID for the delivered message. --girish -- View this message in context: http://qpid.2158936.n2.nabble.com/Re-delete-message-from-Queue-through-Java-code-tp7663338p7663354.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7462) [Java Broker] Add experimental "pull" consumers to the broker
[ https://issues.apache.org/jira/browse/QPID-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7462: - Attachment: 0001-QPID-7462-6.0.x_updated-after-sparse-memory-protecti.patch > [Java Broker] Add experimental "pull" consumers to the broker > - > > Key: QPID-7462 > URL: https://issues.apache.org/jira/browse/QPID-7462 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-7462-6.0.x_updated-after-sparse-memory-protecti.patch, > QPID-7462_6.0.x_updated.patch, QPID-7462.patch > > > As per > [this|http://qpid.2158936.n2.nabble.com/Qpid-broker-6-0-4-performance-issues-tp7652036.html] > thread on the users list, our eventual goal is the elimination of the queue > runners and moving to a model where the connection threads pull messages from > the queues. In particular this allows multi-queue consumers to act in a > "fair" manner between the multiple queues the consumer is associated with -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7462) [Java Broker] Add experimental "pull" consumers to the broker
[ https://issues.apache.org/jira/browse/QPID-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7462: - Attachment: (was: 0001-QPID-7462-6.0.x_updated-after-sparse-memory-protecti.patch) > [Java Broker] Add experimental "pull" consumers to the broker > - > > Key: QPID-7462 > URL: https://issues.apache.org/jira/browse/QPID-7462 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-6.1 > > Attachments: QPID-7462_6.0.x_updated.patch, QPID-7462.patch > > > As per > [this|http://qpid.2158936.n2.nabble.com/Qpid-broker-6-0-4-performance-issues-tp7652036.html] > thread on the users list, our eventual goal is the elimination of the queue > runners and moving to a model where the connection threads pull messages from > the queues. In particular this allows multi-queue consumers to act in a > "fair" manner between the multiple queues the consumer is associated with -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7689) Consider message header size where appropriate
[ https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7689: --- Summary: Consider message header size where appropriate (was: Queue depth alerting / flow to disk should consider header size too) > Consider message header size where appropriate > -- > > Key: QPID-7689 > URL: https://issues.apache.org/jira/browse/QPID-7689 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The changes introduced by QPID-7618 have the broker track the size of each > queue including header.The new ring queue policy and producer flow > control now consider messages sizes including header. The queue depth > alerting and flow to disk ought to be consistent. > Is there actually value tracking queue size and queue size including header > separately? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7689) Queue depth alerting / flow to disk should consider header size too
[ https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022647#comment-16022647 ] Lorenz Quack commented on QPID-7689: The scope of this JIRA has been expanded (and the title adjusted to reflect this). Places that currently use message size without headers that should also consider the header size are: * Queue depth alerting * Message based queue alerting * QueueStatistics: en-/dequeued, persistent, unacked, and available * Consumer: unacknowledged and delivered stats * Exchange: routed, dropped, and received stats * Connection: received, delivered MessageInfo currently only exposes the message size without header. It should also expose the size of the header. CreditManagers will continue to use only the size of the message body without the header. > Queue depth alerting / flow to disk should consider header size too > > > Key: QPID-7689 > URL: https://issues.apache.org/jira/browse/QPID-7689 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The changes introduced by QPID-7618 have the broker track the size of each > queue including header.The new ring queue policy and producer flow > control now consider messages sizes including header. The queue depth > alerting and flow to disk ought to be consistent. > Is there actually value tracking queue size and queue size including header > separately? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7689) [Java Broker] Consider message header size where appropriate
[ https://issues.apache.org/jira/browse/QPID-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7689: --- Summary: [Java Broker] Consider message header size where appropriate (was: Consider message header size where appropriate) > [Java Broker] Consider message header size where appropriate > > > Key: QPID-7689 > URL: https://issues.apache.org/jira/browse/QPID-7689 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The changes introduced by QPID-7618 have the broker track the size of each > queue including header.The new ring queue policy and producer flow > control now consider messages sizes including header. The queue depth > alerting and flow to disk ought to be consistent. > Is there actually value tracking queue size and queue size including header > separately? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7640) [Java Broker] Migrate qpid-java svn to git
[ https://issues.apache.org/jira/browse/QPID-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022641#comment-16022641 ] ASF subversion and git services commented on QPID-7640: --- Commit 1f422ede1414c0b26f42f382a43e3fdeb2653b7a in qpid-broker-j's branch refs/heads/6.0.x from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=1f422ed ] QPID-7640: Change scm info in pom.xml from svn to git. Cherry picked from master 3aa3a86de8b67b91d1a3d7137439ad92f1079c18 > [Java Broker] Migrate qpid-java svn to git > --- > > Key: QPID-7640 > URL: https://issues.apache.org/jira/browse/QPID-7640 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two > components that use SVN. We should migrate from to GIT. This will simplify > the site. > Related vote thread: > http://qpid.2158936.n2.nabble.com/RESULT-VOTE-Migrate-Qpid-Broker-J-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7662060.html > Release discuss thread: > http://qpid.2158936.n2.nabble.com/DISCUSS-Migrate-Qpid-Broker-for-Java-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7661505.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7640) [Java Broker] Migrate qpid-java svn to git
[ https://issues.apache.org/jira/browse/QPID-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022620#comment-16022620 ] ASF subversion and git services commented on QPID-7640: --- Commit 3aa3a86de8b67b91d1a3d7137439ad92f1079c18 in qpid-broker-j's branch refs/heads/6.1.x from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3aa3a86 ] QPID-7640: Change scm info in pom.xml from svn to git. Cherry picked from master b8981a7dd9ecf183ded7a3e74a2de1ec190f2e99 > [Java Broker] Migrate qpid-java svn to git > --- > > Key: QPID-7640 > URL: https://issues.apache.org/jira/browse/QPID-7640 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Keith Wall >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two > components that use SVN. We should migrate from to GIT. This will simplify > the site. > Related vote thread: > http://qpid.2158936.n2.nabble.com/RESULT-VOTE-Migrate-Qpid-Broker-J-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7662060.html > Release discuss thread: > http://qpid.2158936.n2.nabble.com/DISCUSS-Migrate-Qpid-Broker-for-Java-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7661505.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7731) Upgrade to Jetty 9.4
[
https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022521#comment-16022521
]
Keith Wall edited comment on QPID-7731 at 5/24/17 9:15 AM:
---
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}} that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty.I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
# {{MarkableEndPoint#fillPreserved}} is badly named. {{fillFromPreserved}} or
{{writePerserved}} would be clearer. {{filledByteNumber}} is a mysterious
name. I'd suggest simply {{filled}}.
was (Author: k-wall):
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}} that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty.I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
> Upgrade to Jetty 9.4
>
>
> Key: QPID-7731
> URL: https://issues.apache.org/jira/browse/QPID-7731
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch
>
>
> The version of Jetty used by the Java Broker is v8.1. This is now marked as
> EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an
> option now we are on Java 8). The Jetty API has changed substantially so
> the HTTP Management is probably going to need a deep rewrite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional comm
[jira] [Commented] (QPID-7775) Flow to disk should consider the size of the resident messages in memory.
[ https://issues.apache.org/jira/browse/QPID-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022576#comment-16022576 ] ASF subversion and git services commented on QPID-7775: --- Commit d1b534892147b49fd27834fb09596cf6372530d0 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d1b5348 ] QPID-7775: [Java Broker] Separate flowToDiskCheckPeriod from housekeepingCheckPeriod > Flow to disk should consider the size of the resident messages in memory. > - > > Key: QPID-7775 > URL: https://issues.apache.org/jira/browse/QPID-7775 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > Our current algorithm for triggering flow to disk has some shortcomings. > * the algorithm does not account for memory returned by flow to disk. > The decision to flow a message a newly arriving message to disk > considers only the queue's target size and queue's depth. Once a > queue depth is over its target, all messages will go to disk even if > all messages have actually been flowed to disk. The same is true > after recovery: flow to disk will be enabled even though there are no > messages in RAM. > * the fact that a queue's target size is assigned by periodically by > housekeeping means that the queues target size can be wrong for most > of the time. This is very apparent if a queue is growing; you > actually see *most* messages flowing to disk even when there is ample > memory. The target size is periodically recomputed but only remains > correct for an instant, the queue returns to the flow to disk state as > more messages are added. We see this during perf test runs. > We will change the MessageStore so that it tracks the size of the messages > that are held resident in memory.The flow to disk algorithm will be > change to by triggered when the resident memory exceeds the virtual host's > target size. > This work is likely to fully replace the recent work done on QPID-7770. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7731) Upgrade to Jetty 9.4
[
https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022521#comment-16022521
]
Keith Wall edited comment on QPID-7731 at 5/24/17 8:25 AM:
---
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}} that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty.I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
was (Author: k-wall):
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}}s that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty.I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
> Upgrade to Jetty 9.4
>
>
> Key: QPID-7731
> URL: https://issues.apache.org/jira/browse/QPID-7731
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch
>
>
> The version of Jetty used by the Java Broker is v8.1. This is now marked as
> EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an
> option now we are on Java 8). The Jetty API has changed substantially so
> the HTTP Management is probably going to need a deep rewrite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7731) Upgrade to Jetty 9.4
[
https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022521#comment-16022521
]
Keith Wall commented on QPID-7731:
--
My comments are:
# We have a mixture of acceptsBacklog (HttpPort#getAcceptsBacklogSize) and
acceptBacklog (HttpPort#PORT_HTTP_ACCEPT_BACKLOG). I think the latter is more
common parlance and it is what we use in the AMQP port.
# Unnecessary use of {{double}}
org.apache.qpid.server.model.port.HttpPortImpl#onValidate
# Validation message mentions AMQP rather than HTTP HttpManagement.java:495
# I notice that if the SSLHandshake fails (because of cipher or TLS protocol
disagreement between client and server) we see nothing in the log. This could
be hard to diagnose. Suggest we add a {{SslHandshakeListener}} to the
{{SslConnection}}s that merely logs handshake failure, the endpoint and
underlying error message at INFO. I suggest we log the stack trace if DEBUG
is enabled. Remember the websocket {{SslConnection}} too.
# Regarding the need for the use of the reflection
org/apache/qpid/server/transport/websocket/WebSocketProvider.java:197. Can we
raise a Jetty issue please? I don't see this as a blocker for v7 btw.
# org.apache.qpid.server.model.port.HttpPortImpl#onOpen I see you have
duplicated the logic for sizing acceptors and selectors from Jetty.I think
we could avoid the duplication (and the risk of this code rotting) if we used a
pair of derived attributes. For {{numberOfAcceptors}} we would have
{{getDesiredNumberOfAcceptors()}} which would back the context variable and
derived attribute getNumberOfAcceptors() which would expose the value that
Jetty has decided to use which is obtainable from
{{org.eclipse.jetty.server.AbstractConnector#getAcceptors}}. For selectors,
the call is org.eclipse.jetty.io.SelectorManager#getSelectorCount.
> Upgrade to Jetty 9.4
>
>
> Key: QPID-7731
> URL: https://issues.apache.org/jira/browse/QPID-7731
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch,
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch
>
>
> The version of Jetty used by the Java Broker is v8.1. This is now marked as
> EOL by the Jetty development team. We should upgrade to Jetty v9.4 (an
> option now we are on Java 8). The Jetty API has changed substantially so
> the HTTP Management is probably going to need a deep rewrite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost with attached links.
[
https://issues.apache.org/jira/browse/QPID-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16008227#comment-16008227
]
Lorenz Quack edited comment on QPID-7781 at 5/24/17 8:09 AM:
-
This also happens
* without any connected clients.
* with no queues on the VH.
* with the JSON/BDB VHN/VH
was (Author: lorenz.quack):
This also happens without any connected clients.
> [Java Broker] 500 error whilst deleting a virtualhost with attached links.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed
> virtualhostnode/virtualhost. The virtualhost had three messages on two
> queues. Clients were connected to the queues at the time (stopped on a
> breakpoint). The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at
> com.google.common.util.con
[jira] [Updated] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost.
[
https://issues.apache.org/jira/browse/QPID-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7781:
---
Summary: [Java Broker] 500 error whilst deleting a virtualhost. (was:
[Java Broker] 500 error whilst deleting a virtualhost with attached links.)
> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed
> virtualhostnode/virtualhost. The virtualhost had three messages on two
> queues. Clients were connected to the queues at the time (stopped on a
> breakpoint). The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$4.onSuccess(AbstractConfiguredObject.java:808)
> a
Re: Help to build the Java Qpid broker build from source
If you run mvn clean package -DskipTests it will create a zip file: broker\target\qpid-broker-7.0.0-SNAPSHOT-bin.zip you can then unzip this file somewhere else to create an installation directory which has all the files in the right place such that the bin\qpid-server.bat file will work correctly from within that installation directory (see http://qpid.apache.org/releases/qpid-java-6.1.2/java-broker/book/Java-Broker-Installation-InstallationWindows.html ). Hope this helps, Rob On 24 May 2017 at 08:31, girishlc wrote: > Hi Keith, > > Thanks for your response, > > Actually I am using the same link which you sent. > > https://cwiki.apache.org/confluence/display/qpid/qpid+java+build+how+to > > Issue 1. > > There are executable already present in this folder and I can directly use > this, > C:\queuSrc\qpid-broker\broker\bin > For ex: > C:\queuSrc\qpid-broker\broker\bin\qpid-server > > but I need to build the source and run the qpid-server. > > > Issue 2: > > After the below command, I can see the jar file as mentioned below, > mvn clean install –DskipTests > > ...\qpid-broker\broker-codegen\target > qpid-broker-codegen-7.0.0-SNAPSHOT > > How can I use this to run the qpid-server ? > > > > > -- > View this message in context: http://qpid.2158936.n2.nabble. > com/Help-to-build-the-Java-Qpid-broker-build-from-source- > tp7662674p7663339.html > Sent from the Apache Qpid developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
Re: delete message from Queue through Java code
On 24 May 2017 at 08:45, girishlc wrote: > Hi Gordon, > > Thanks for the reply, > > >>Generally, messages are removed from the queue once they have been > >>acknowledged by the consuming client. The default in JMS is (I believe) > >>auto-acknowledge, so when your message listener's onMessage() returns, > >>the library will automatically acknowledge the queue. > > 1. Actually what if some other client also wants to read that message ? > When using JMS consumers against a queue it is defined that only one consumer will get the message. The only way to read messages from a queue while allowing other clients to also read the same message from the same queue is to use Queue Browsing > 2. Is there any setting that we need to do at Qpid WebManagement portal ? > I can see the status of the message changes from "Available" to > "Acquired" after reading the message from Client, but how to remove this > from the Queue. > Just for clarity, when you say the Qpid Web Management portal, which product are you describing - are you using the Qpid Broker for Java with its built in web console, or a different broker / web management console? > 3. Is there any method to delete the message based on the "Message Id" > JMS does not really have a concept of "deleting" a message. One approach (and not a particularly nice one) is (presuming that you have used a queue browser initially) to create a new consumer for the queue with a selector based on the JMSMessageID. Since the JMSMessageID is unique then that consumer should bring back one message (if the message has not already been deleted), or zero messages if it has been deleted. In general I'd try to avoid this pattern though as it requires creating a new consumer for each message, then closing it again, which is not very efficient. -- Rob > > >>I'm not sure what you mean by 'read module' though. Are you using JMS to > >>consume messages? Or some other API > I'm using JMS in that I've created the new module called read module > which reads the message from Qpid. > > > > > > -- > View this message in context: http://qpid.2158936.n2.nabble. > com/Re-delete-message-from-Queue-through-Java-code-tp7663338p7663340.html > Sent from the Apache Qpid developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
Re: delete message from Queue through Java code
On 24/05/17 08:45, girishlc wrote: Hi Gordon, Thanks for the reply, Generally, messages are removed from the queue once they have been acknowledged by the consuming client. The default in JMS is (I believe) auto-acknowledge, so when your message listener's onMessage() returns, the library will automatically acknowledge the queue. 1. Actually what if some other client also wants to read that message ? If you want to view messages without consuming them, you should use the QueueBrowser part of the API. 2. Is there any setting that we need to do at Qpid WebManagement portal ? I can see the status of the message changes from "Available" to "Acquired" after reading the message from Client, but how to remove this from the Queue. When the consuming client acknowledges the acquired message, it should be removed. 3. Is there any method to delete the message based on the "Message Id" Not directly, no. You could consume using a selector the picks a particular message id. That is not terribly efficient though as it's not really the mode of operation brokers were designed for. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: delete message from Queue through Java code
Hi Gordon, Thanks for the reply, >>Generally, messages are removed from the queue once they have been >>acknowledged by the consuming client. The default in JMS is (I believe) >>auto-acknowledge, so when your message listener's onMessage() returns, >>the library will automatically acknowledge the queue. 1. Actually what if some other client also wants to read that message ? 2. Is there any setting that we need to do at Qpid WebManagement portal ? I can see the status of the message changes from "Available" to "Acquired" after reading the message from Client, but how to remove this from the Queue. 3. Is there any method to delete the message based on the "Message Id" >>I'm not sure what you mean by 'read module' though. Are you using JMS to >>consume messages? Or some other API I'm using JMS in that I've created the new module called read module which reads the message from Qpid. -- View this message in context: http://qpid.2158936.n2.nabble.com/Re-delete-message-from-Queue-through-Java-code-tp7663338p7663340.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Help to build the Java Qpid broker build from source
Hi Keith, Thanks for your response, Actually I am using the same link which you sent. https://cwiki.apache.org/confluence/display/qpid/qpid+java+build+how+to Issue 1. There are executable already present in this folder and I can directly use this, C:\queuSrc\qpid-broker\broker\bin For ex: C:\queuSrc\qpid-broker\broker\bin\qpid-server but I need to build the source and run the qpid-server. Issue 2: After the below command, I can see the jar file as mentioned below, mvn clean install –DskipTests ...\qpid-broker\broker-codegen\target qpid-broker-codegen-7.0.0-SNAPSHOT How can I use this to run the qpid-server ? -- View this message in context: http://qpid.2158936.n2.nabble.com/Help-to-build-the-Java-Qpid-broker-build-from-source-tp7662674p7663339.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: delete message from Queue through Java code
On 24/05/17 06:52, girish lc wrote: Hi Team, I need help in deleting the message from the Queue in Qpid through Java code. Current status: I am sending the messages to the Qpid Queue using JMS and from the Queue I'm reading the messages through read module and now I need to delete the particular message from the Queue based on some event. May I have any code or API for this. Generally, messages are removed from the queue once they have been acknowledged by the consuming client. The default in JMS is (I believe) auto-acknowledge, so when your message listener's onMessage() returns, the library will automatically acknowledge the queue. I'm not sure what you mean by 'read module' though. Are you using JMS to consume messages? Or some other API? - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
