[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634337#comment-16634337
]
Alex Rudyy commented on QPID-8245:
--
[~rgodfrey] Attached patch
'{{0008-QPID-8245-Dispose-QpidByteBuffer-on-decoding-FieldTa.patch}}'
addressing review comments
> [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
> --
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch,
> 0006-QPID-8245-some-code-clean-up.patch,
> 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch,
> 0008-QPID-8245-Dispose-QpidByteBuffer-on-decoding-FieldTa.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8245: - Attachment: 0008-QPID-8245-Dispose-QpidByteBuffer-on-decoding-FieldTa.patch > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch, > 0008-QPID-8245-Dispose-QpidByteBuffer-on-decoding-FieldTa.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8245: - Attachment: (was: 0005-QPID-8245-Split-field-table-into-2-implementations.patch) > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch, > 0008-QPID-8245-Dispose-QpidByteBuffer-on-decoding-FieldTa.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1134) Console test should be skipped if it was manually executed but console was not built
[ https://issues.apache.org/jira/browse/DISPATCH-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1134. Resolution: Fixed Fix Version/s: 1.4.0 > Console test should be skipped if it was manually executed but console was > not built > > > Key: DISPATCH-1134 > URL: https://issues.apache.org/jira/browse/DISPATCH-1134 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.4.0 > > > If you don't build the console during a router build, then when you run the > system tests the console should not be tested. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1134) Console test should be skipped if it was manually executed but console was not built
[ https://issues.apache.org/jira/browse/DISPATCH-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated DISPATCH-1134: --- Summary: Console test should be skipped if it was manually executed but console was not built (was: Console tests should be skipped (instead of failing) if console is not installed) > Console test should be skipped if it was manually executed but console was > not built > > > Key: DISPATCH-1134 > URL: https://issues.apache.org/jira/browse/DISPATCH-1134 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > If you don't build the console during a router build, then when you run the > system tests the console should not be tested. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1134) Console tests should be skipped (instead of failing) if console is not installed
[ https://issues.apache.org/jira/browse/DISPATCH-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634248#comment-16634248 ] ASF subversion and git services commented on DISPATCH-1134: --- Commit 4031dddee1f25e40529c60ebe68c31a3dbabe45c in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4031ddd ] DISPATCH-1134 Skip console test if test is manually run but the console was not built > Console tests should be skipped (instead of failing) if console is not > installed > > > Key: DISPATCH-1134 > URL: https://issues.apache.org/jira/browse/DISPATCH-1134 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.3.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > If you don't build the console during a router build, then when you run the > system tests the console should not be tested. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1945) Azure ServiceBus: Sent messages are lost
[
https://issues.apache.org/jira/browse/PROTON-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Meier updated PROTON-1945:
---
Description:
A python-instance based on v0.24.0 is used to receive and send messages from/to
a Azure ServiceBus instance.
The affected software, which runs inside a Docker container and which is based
on Python 3.6, is already used since a few weeks. From time to time the
conatiner(s) may restart, which is not a problem.
The application receives exactly one message from the Azue ServiceBus and sends
exactly one message back when the work is done. Qpid Proton is easy to use and
always worked well, but this weekend I had a problem: The application still
received messages and successfully handled them. It also sent and
"answer"-message, but they never appeared in the Azure ServiceBus.
I started another process on one of the two available affected containers. This
second process worked without any problems. As I found out a restart of the
containers (more precisely: "affected" processes) solved the problem.
Unfortunately, it is very critical for the given application that sent messages
are really received by the Azure ServiceBus. Or if this doesn't work, that it
is possible to know that this doesn't work. Usually, if the connection is
broken (or sending messages doesn't work) Qpid Proton handles this case (incl.
logging).
Connection initialization:
{code:java}
self._connection =
container.connect("amqps://a:b...@xyz.servicebus.windows.net",
shared_access_key_value="key",
service_namespace="namespace"
), heartbeat=self.heartbeat_ms)
def _get_session(self):
session = self._connection.session()
session.open()
return session{code}
Initialize receiver:
{code:java}
self._receiver = event.container.create_receiver(self._get_session(),
self._source_queue_name)
self._receiver.capacity = self.capacity{code}
Initialize sender:
{code:java}
self._sender = event.container.create_sender(self._get_session(),
self._target_queue_name){code}
Do I do something wrong? Or are there any bugs in combination with the
ServiceBus known? Unfortunately, I was not able to collect much debug
information during the runtime, but is there a possibility that I can collect
useful information if this happens again?
It might be useful to know that during the period while this happend, the
ServiceBus topology was not changed/updated.
Thank you very much
was:
A python-instance based on v0.24.0 is used to receive and send messages from/to
a Azure ServiceBus instance.
The affected software, which runs inside a Docker container and which is based
on Python 3.6, is already used since a few weeks. From time to time the
conatiner(s) may restart, which is not a problem.
The application receives exactly one message from the Azue ServiceBus and sends
exactly one message back when the work is done. Qpid Proton is easy to use and
always worked well, but this weekend I had a problem: The application still
received messages and successfully handled them. It also sent and
"answer"-message, but they never appeared in the Azure ServiceBus.
I started another process on one of the two available affected containers. This
second process worked without any problems. As I found out a restart of the
containers (more precisely: "affected" processes) solved the problem.
Unfortunately, it is very critical for the given application that sent messages
are really received by the Azure ServiceBus. Or if this doesn't work, that it
is possible to know that this doesn't work.
Connection initialization:
{code:java}
self._connection =
container.connect("amqps://a:b...@xyz.servicebus.windows.net",
shared_access_key_value="key",
service_namespace="namespace"
), heartbeat=self.heartbeat_ms)
def _get_session(self):
session = self._connection.session()
session.open()
return session{code}
Initialize receiver:
{code:java}
self._receiver = event.container.create_receiver(self._get_session(),
self._source_queue_name)
self._receiver.capacity = self.capacity{code}
Initialize sender:
{code:java}
self._sender = event.container.create_sender(self._get_session(),
self._target_queue_name){code}
Do I do something wrong? Or are there any bugs in combination with the
ServiceBus known? Unfortunately, I was not able to collect much debug
information during the runtime, but is there a possibility that I can collect
useful information if this happens again?
It might be useful to know that during the period while this happend, the
ServiceBus topology was not changed/updated.
Thank you very much
> Azure ServiceBus: Sent messages are lost
>
>
> Key: PROTON-1945
> URL: https://issues.apache.org/jira/browse/PROTON-1945
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: prot
[jira] [Created] (PROTON-1945) Azure ServiceBus: Sent messages are lost
Benjamin Meier created PROTON-1945:
--
Summary: Azure ServiceBus: Sent messages are lost
Key: PROTON-1945
URL: https://issues.apache.org/jira/browse/PROTON-1945
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: proton-c-0.24.0
Environment: Docker (Kubernetes) / Azure ServiceBus
Reporter: Benjamin Meier
A python-instance based on v0.24.0 is used to receive and send messages from/to
a Azure ServiceBus instance.
The affected software, which runs inside a Docker container and which is based
on Python 3.6, is already used since a few weeks. From time to time the
conatiner(s) may restart, which is not a problem.
The application receives exactly one message from the Azue ServiceBus and sends
exactly one message back when the work is done. Qpid Proton is easy to use and
always worked well, but this weekend I had a problem: The application still
received messages and successfully handled them. It also sent and
"answer"-message, but they never appeared in the Azure ServiceBus.
I started another process on one of the two available affected containers. This
second process worked without any problems. As I found out a restart of the
containers (more precisely: "affected" processes) solved the problem.
Unfortunately, it is very critical for the given application that sent messages
are really received by the Azure ServiceBus. Or if this doesn't work, that it
is possible to know that this doesn't work.
Connection initialization:
{code:java}
self._connection =
container.connect("amqps://a:b...@xyz.servicebus.windows.net",
shared_access_key_value="key",
service_namespace="namespace"
), heartbeat=self.heartbeat_ms)
def _get_session(self):
session = self._connection.session()
session.open()
return session{code}
Initialize receiver:
{code:java}
self._receiver = event.container.create_receiver(self._get_session(),
self._source_queue_name)
self._receiver.capacity = self.capacity{code}
Initialize sender:
{code:java}
self._sender = event.container.create_sender(self._get_session(),
self._target_queue_name){code}
Do I do something wrong? Or are there any bugs in combination with the
ServiceBus known? Unfortunately, I was not able to collect much debug
information during the runtime, but is there a possibility that I can collect
useful information if this happens again?
It might be useful to know that during the period while this happend, the
ServiceBus topology was not changed/updated.
Thank you very much
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1135) Router A leaks memory when router B killed and restarted.
michael goulish created DISPATCH-1135:
-
Summary: Router A leaks memory when router B killed and restarted.
Key: DISPATCH-1135
URL: https://issues.apache.org/jira/browse/DISPATCH-1135
Project: Qpid Dispatch
Issue Type: Bug
Reporter: michael goulish
I set up a 2-node router network, with B connecting to A.
No clients.
Repeatedly killing and restarting B – giving 3 seconds after each kill and
after each restart for the network to settle down. Repeated 100 times. The
same router A ran for the duration of the test.
The 'ps' program, run repeatedly on router A, indicated that it was leaking
about 82 KB per kill-and-restart. Using 'qdstat m' on A after each
kill-and-restart showed the following difference between iteration 1 and
iteration 100. ( Note, this shows growth of only 44 KB per iteration. )
As far as I looked into the past (about 1 year) I saw similar behavior.
In the chart below, the first column "size" is the number of bytes in a single
struct of that type.
"In-threads" means how many of each struct are currently being used.
Note that, although there are no clients, the routers will be sending some
messages to each other.
{{type size in-threads in-threads item byte}}
{{ test 1 test 100 growth growth}}
{{ ==}}
{{qd_buffer_t 536 256 2944 2688 1440768}}
{{ qd_message_content_t 1056 128 1216 1088 1148928}}
{{ qd_iterator_t 160 448 7488 7040 1126400}}
{{ qd_parsed_field_t 88 256 2880 2624 230912}}
{{ qdr_delivery_t 248 256 1152 896 08}}
{{ qd_message_t 160 256 1088 832 133120}}
{{ qd_connection_t 2320 32 64 32 74240}}
{{ qdr_general_work_t 64 64 448 384 24576}}
{{ qdr_link_t 360 192 256 64 23040}}
{{ qd_bitmask_t 24 192 1088 896 21504}}
{{ qdr_connection_work_t 48 64 384 320 15360}}
{{ qdr_link_work_t 48 64 384 320 15360}}
{{ qd_link_t 96 128 256 128 12288}}
{{ qdr_link_ref_t 24 64 448 384 9216}}
{{ qd_parsed_turbo_t 64 128 256 128 8192}}
{{ qd_link_ref_t 24 64 256 192 4608}}
{{ qdr_error_t 24 64 256 192 4608}}
{{ qd_deferred_call_t 32 64 192 128 4096}}
{{ qdr_terminus_t 64 192 256 64 4096}}
{{ qdr_delivery_ref_t 24 64 128 64 1536}}
( All other structs have zero growth. (Or, in one case, less.) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1893) [c] idle-timeout set in REMOTE_OPEN does not take immediate effect.
[ https://issues.apache.org/jira/browse/PROTON-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1893: --- Fix Version/s: (was: proton-c-0.26.0) proton-c-0.27.0 > [c] idle-timeout set in REMOTE_OPEN does not take immediate effect. > --- > > Key: PROTON-1893 > URL: https://issues.apache.org/jira/browse/PROTON-1893 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.24.0 >Reporter: Alan Conway >Assignee: Cliff Jansen >Priority: Major > Fix For: proton-c-0.27.0 > > > If idle-timeout is set on the server in a PN_CONNECTION_REMOTE_OPEN event, it > is correctly sent to the peer in the OPEN frame, but the local timer is not > activated until the first data is read or written on the connection. If the > client never sends another frame, the server does not time out the connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1933) [go] error from ill-formed message is not reported
[ https://issues.apache.org/jira/browse/PROTON-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1933: --- Fix Version/s: (was: proton-c-0.26.0) proton-c-0.27.0 > [go] error from ill-formed message is not reported > -- > > Key: PROTON-1933 > URL: https://issues.apache.org/jira/browse/PROTON-1933 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > If an invalid (e.g. truncated) message is received on an > electron.Receiver.Receive() it returns (nil, nil), instead of an error. The > error is detected by the proton library, it should be returned by Receive() -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1944) 0.27.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1944: --- Fix Version/s: (was: proton-c-0.26.0) proton-c-0.27.0 > 0.27.0 release tasks > > > Key: PROTON-1944 > URL: https://issues.apache.org/jira/browse/PROTON-1944 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: proton-c-0.27.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1926) 0.26.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634031#comment-16634031 ] ASF subversion and git services commented on PROTON-1926: - Commit 1b554aad70452d6501cb3e13a6c10186d14e9dc9 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b554aa ] PROTON-1944, PROTON-1926: update versions for 0.27.0-SNAPSHOT > 0.26.0 release tasks > > > Key: PROTON-1926 > URL: https://issues.apache.org/jira/browse/PROTON-1926 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: proton-c-0.26.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1944) 0.27.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634030#comment-16634030 ] ASF subversion and git services commented on PROTON-1944: - Commit 1b554aad70452d6501cb3e13a6c10186d14e9dc9 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b554aa ] PROTON-1944, PROTON-1926: update versions for 0.27.0-SNAPSHOT > 0.27.0 release tasks > > > Key: PROTON-1944 > URL: https://issues.apache.org/jira/browse/PROTON-1944 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: proton-c-0.26.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1926) 0.26.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634029#comment-16634029 ] ASF subversion and git services commented on PROTON-1926: - Commit fd518f29b532c4e692ca7684b0917234e4bfff1d in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fd518f2 ] PROTON-1926: update versions for 0.26.0-rc1 > 0.26.0 release tasks > > > Key: PROTON-1926 > URL: https://issues.apache.org/jira/browse/PROTON-1926 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: proton-c-0.26.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1944) 0.27.0 release tasks
Robbie Gemmell created PROTON-1944: -- Summary: 0.27.0 release tasks Key: PROTON-1944 URL: https://issues.apache.org/jira/browse/PROTON-1944 Project: Qpid Proton Issue Type: Task Components: proton-c, release Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: proton-c-0.26.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1926) 0.26.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633860#comment-16633860 ] ASF subversion and git services commented on PROTON-1926: - Commit 2149ad68ae1ba3db09ba70b96a4bb4d9991f5ddc in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2149ad6 ] PROTON-1926: bump so versions based on review by Justin, Andrew, Alan, and Cliff. > 0.26.0 release tasks > > > Key: PROTON-1926 > URL: https://issues.apache.org/jira/browse/PROTON-1926 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: proton-c-0.26.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633855#comment-16633855 ] Rob Godfrey commented on QPID-8245: --- [~alex.rufous] Ah - I forgot about that flow to disk feature :-) > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0005-QPID-8245-Split-field-table-into-2-implementations.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633790#comment-16633790
]
Alex Rudyy commented on QPID-8245:
--
[~rgodfrey] Thanks for spotting the embarrassing defect with leaking of QBB. I
fill fix that. As for removal of field {{_properties}}, I will try to provide
another patch removing {{_properties}} and adding {{_cach}} field to hold the
decoded values. I originally did not want to do that, as, at the moment, the
flow to disk functionality decodes the headers and stores them in
{{_properties}} for future references. It seems that after removal of field
{{_properties}} from {{FieldTable}}, we need to add a mechanism to reload
metadata and re-created headers {{FieldTable}} for messages flowed to disk. The
same should occur for functionality reallocation QBB to avoid memory
fragmentation.
> [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
> --
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch,
> 0005-QPID-8245-Split-field-table-into-2-implementations.patch,
> 0006-QPID-8245-some-code-clean-up.patch,
> 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633750#comment-16633750
]
Rob Godfrey edited comment on QPID-8245 at 10/1/18 9:18 AM:
[~alex.rufous] Yes - that was my intent, I just also imagined changing the name
to imply that the map was no longer a reference of all the properties, but just
a cache of some of them
One comment on your patch, in FieldTable.java:
{code:java}
QpidByteBuffer dup = _encodedForm.duplicate();
while(dup.hasRemaining())
{
final byte[] bytes = AMQShortString.readAMQShortStringAsBytes(dup);
if(Arrays.equals(keyBytes, bytes))
{
return AMQTypedValue.readFromBuffer(dup);
}
else
{
AMQType type = AMQTypeMap.getType(dup.get());
type.skip(dup);
}
}
{code}
Shouldn't his be
{code:java}
try(QpidByteBuffer dup = _encodedForm.duplicate())
{
while(dup.hasRemaining())
{
final byte[] bytes = AMQShortString.readAMQShortStringAsBytes(dup);
if(Arrays.equals(keyBytes, bytes))
{
return AMQTypedValue.readFromBuffer(dup);
}
else
{
AMQType type = AMQTypeMap.getType(dup.get());
type.skip(dup);
}
}
}
{code}
To stop the duplicate leaking?
was (Author: rgodfrey):
[~alex.rufous] Yes - that was my intent, I just also imagined changing the name
to imply that the map was no longer a reference of all the properties, but just
a cache of some of them
> [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
> --
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch,
> 0005-QPID-8245-Split-field-table-into-2-implementations.patch,
> 0006-QPID-8245-some-code-clean-up.patch,
> 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633750#comment-16633750 ] Rob Godfrey commented on QPID-8245: --- [~alex.rufous] Yes - that was my intent, I just also imagined changing the name to imply that the map was no longer a reference of all the properties, but just a cache of some of them > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0005-QPID-8245-Split-field-table-into-2-implementations.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
