[jira] [Commented] (QPIDJMS-411) Improve out of the the frame tracing loggers to include the binary payload
[ https://issues.apache.org/jira/browse/QPIDJMS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586087#comment-16586087 ] ASF subversion and git services commented on QPIDJMS-411: - Commit 6076c58424c5032e888c82e4af7be56c299834ee in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=6076c58 ] QPIDJMS-411: remove extra space after performative or before payload > Improve out of the the frame tracing loggers to include the binary payload > -- > > Key: QPIDJMS-411 > URL: https://issues.apache.org/jira/browse/QPIDJMS-411 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.36.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.37.0 > > > When the 'amqp.traceFrames' option is enabled the tracing only includes the > TransportFrame content and not the optional payload data. Improve this > logging to include a string formatted representation of the payload data. -- 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-8230) [Broker-J] Virtual Host children can be partially recovered and left in memory on failed Virtual Host startup
[ https://issues.apache.org/jira/browse/QPID-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8230: - Description: When Virtual Host startup fails (for example, due to defect QPID-8229) some of its children could be recovered and stored in virtual host internal data structures. The subsequent virtual host restarts can fail with another error "409 - Child of type already exists with id of ". This error masks the original error causing virtual host failure in first place. No error is reported into the broker logs. If original error causing first virtual host startup failure can be fixed, the VHN restart or Broker restart can resolve "409 - Child of type already exists with id of " was: When Virtual Host startup fails, for example, due to defect QPID-8229, some of the its children could be recovered and stored in virtual host internal data structures. The subsequent virtual host restarts can fail with another error "409 - Child of type already exists with id of ". This error masks the original error causing virtual host failure in first place. No error is reported into the broker logs. If original error causing first virtual host startup failure can be fixed, the VHN restart or Broker restart can resolve "409 - Child of type already exists with id of " > [Broker-J] Virtual Host children can be partially recovered and left in > memory on failed Virtual Host startup > - > > Key: QPID-8230 > URL: https://issues.apache.org/jira/browse/QPID-8230 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > > When Virtual Host startup fails (for example, due to defect QPID-8229) some > of its children could be recovered and stored in virtual host internal data > structures. The subsequent virtual host restarts can fail with another error > "409 - Child of type already exists with id of ". This error masks > the original error causing virtual host failure in first place. > No error is reported into the broker logs. If original error causing first > virtual host startup failure can be fixed, the VHN restart or Broker restart > can resolve "409 - Child of type already exists with id of " -- 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-8230) [Broker-J] Virtual Host children can be partially recovered and left in memory on failed Virtual Host startup
[ https://issues.apache.org/jira/browse/QPID-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8230: - Summary: [Broker-J] Virtual Host children can be partially recovered and left in memory on failed Virtual Host startup (was: [Broker-J] Failed Virtual Host restart can partially recover some of the queues and leave them in memory) > [Broker-J] Virtual Host children can be partially recovered and left in > memory on failed Virtual Host startup > - > > Key: QPID-8230 > URL: https://issues.apache.org/jira/browse/QPID-8230 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > > When Virtual Host startup fails, for example, due to defect QPID-8229, some > of the its children could be recovered and stored in virtual host internal > data structures. The subsequent virtual host restarts can fail with another > error "409 - Child of type already exists with id of ". This error > masks the original error causing virtual host failure in first place. > No error is reported into the broker logs. If original error causing first > virtual host startup failure can be fixed, the VHN restart or Broker restart > can resolve "409 - Child of type already exists with id of " -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8230) [Broker-J] Failed Virtual Host restart can partially recover some of the queues and leave them in memory
Alex Rudyy created QPID-8230: Summary: [Broker-J] Failed Virtual Host restart can partially recover some of the queues and leave them in memory Key: QPID-8230 URL: https://issues.apache.org/jira/browse/QPID-8230 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.0.6, qpid-java-6.1.6 Reporter: Alex Rudyy When Virtual Host startup fails, for example, due to defect QPID-8229, some of the its children could be recovered and stored in virtual host internal data structures. The subsequent virtual host restarts can fail with another error "409 - Child of type already exists with id of ". This error masks the original error causing virtual host failure in first place. No error is reported into the broker logs. If original error causing first virtual host startup failure can be fixed, the VHN restart or Broker restart can resolve "409 - Child of type already exists with id of " -- 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-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
[
https://issues.apache.org/jira/browse/QPID-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585953#comment-16585953
]
Alex Rudyy commented on QPID-8229:
--
Virtual Host restart is required prior queue deletion in order to reproduce the
issue. It seems MessageStoreConfigurationChangeListener is not set on recovered
objects
> [Broker-J][6.x] Queue bindings are not removed on queue deletion when
> BDB/DERBY/JDBC configuration stores are used
> --
>
> Key: QPID-8229
> URL: https://issues.apache.org/jira/browse/QPID-8229
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-6.1, qpid-java-6.1.2,
> qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-6.1.7
>
>
> Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
> queue deletion. When virtual host with a deleted queue and orphaned binding
> is restarted, the Virtual Host startup fails with error "422 - No parent of
> class Queue found.". The following warning is reported into the logs:
> {noformat}
> WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
> IllegalArgumentException processing request
> http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
> '[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
> {noformat}
> The work-around for the issue would a deletion of all queue bindings prior
> queue deletion. There is no work around which would allow to delete orphaned
> bindings and recover Virtual Host configuration apart from changing store
> data directly which is not feasible in case of BDB.
--
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-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
[
https://issues.apache.org/jira/browse/QPID-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8229:
-
Issue Type: Bug (was: Task)
> [Broker-J][6.x] Queue bindings are not removed on queue deletion when
> BDB/DERBY/JDBC configuration stores are used
> --
>
> Key: QPID-8229
> URL: https://issues.apache.org/jira/browse/QPID-8229
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-6.1, qpid-java-6.1.2,
> qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-6.1.7
>
>
> Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
> queue deletion. When virtual host with a deleted queue and orphaned binding
> is restarted, the Virtual Host startup fails with error "422 - No parent of
> class Queue found.". The following warning is reported into the logs:
> {noformat}
> WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
> IllegalArgumentException processing request
> http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
> '[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
> {noformat}
> The work-around for the issue would a deletion of all queue bindings prior
> queue deletion. There is no work around which would allow to delete orphaned
> bindings and recover Virtual Host configuration apart from changing store
> data directly which is not feasible in case of BDB.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
Alex Rudyy created QPID-8229:
Summary: [Broker-J][6.x] Queue bindings are not removed on queue
deletion when BDB/DERBY/JDBC configuration stores are used
Key: QPID-8229
URL: https://issues.apache.org/jira/browse/QPID-8229
Project: Qpid
Issue Type: Task
Components: Broker-J
Affects Versions: qpid-java-6.1.5, qpid-java-6.1.4, qpid-java-6.1.3,
qpid-java-6.1.2, qpid-java-6.1, qpid-java-6.1.6
Reporter: Alex Rudyy
Fix For: qpid-java-6.1.7
Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
queue deletion. When virtual host with a deleted queue and orphaned binding is
restarted, the Virtual Host startup fails with error "422 - No parent of class
Queue found.". The following warning is reported into the logs:
{noformat}
WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
IllegalArgumentException processing request
http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
'[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
{noformat}
The work-around for the issue would a deletion of all queue bindings prior
queue deletion. There is no work around which would allow to delete orphaned
bindings and recover Virtual Host configuration apart from changing store data
directly which is not feasible in case of BDB.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton-j issue #14: PROTON-1911: Improve performance of EncoderImpl#wri...
Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton-j/pull/14 After some investigation and testing, a different approach (https://github.com/apache/qpid-proton-j/commit/7eac8b945c8ce90f091126d34cf174e8792fdfc0) for improvement was taken as discussed on https://issues.apache.org/jira/browse/PROTON-1911. Could you close this PR? We can only do so via commit messages since this repo is a mirror with limited controls. Thanks, Robbie. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1911) improve performance of String encoding
[ https://issues.apache.org/jira/browse/PROTON-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585735#comment-16585735 ] ASF GitHub Bot commented on PROTON-1911: Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton-j/pull/14 After some investigation and testing, a different approach (https://github.com/apache/qpid-proton-j/commit/7eac8b945c8ce90f091126d34cf174e8792fdfc0) for improvement was taken as discussed on https://issues.apache.org/jira/browse/PROTON-1911. Could you close this PR? We can only do so via commit messages since this repo is a mirror with limited controls. Thanks, Robbie. > improve performance of String encoding > -- > > Key: PROTON-1911 > URL: https://issues.apache.org/jira/browse/PROTON-1911 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.25.0, proton-j-0.28.0 >Reporter: Jens Reimann >Priority: Major > Labels: pull-request-available > Fix For: proton-j-0.29.0 > > Attachments: qpid_encode_1.png, qpid_encode_2.png, qpid_encode_3.png, > qpid_encode_4.png, strings_encode_after.json, strings_encode_before.json > > > Testing has highlighted that the encoding of Strings within messages isn't > very efficient, due to the manner in which the output is written to the > destination buffer. By expanding WritableBuffer to allow writing a String > directly, and improving the String encoding implementation therein we can > improve performance of String encoding. Leveraging PROTON-1913 we can also > provide the previous impl as a default fallback to avoid breaking > compatibility with existing WritableBuffer implementations that lack one. > > Original description: > While digging into performance issues in the Eclipse Hono project I noticed a > high consumption of CPU time when encoding AMQP messages using proton-j. > I made a small reproducer and threw the same profiler at it, here are the > results: > As you can see in the attach screenshot (the first is the initial run with > the current code) most of the time is consumed in > EncoderImpl#writeRaw(String). This due to the fact that is call "put" for > every byte it want to encode. > The following screenshots are from a patched version which uses a small > thread local buffer to locally encode the raw data and then flush it to the > buffer in bigger chunks. > Screenshot 3 and 4 show the improve performance, but also show that the > memory consumption stays low. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8222) [JMS AMQP 0-x][AMQP 0-8..0-91] Transaction commit/rollback or recover can hang when failover is in progress
[
https://issues.apache.org/jira/browse/QPID-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy closed QPID-8222.
> [JMS AMQP 0-x][AMQP 0-8..0-91] Transaction commit/rollback or recover can
> hang when failover is in progress
> ---
>
> Key: QPID-8222
> URL: https://issues.apache.org/jira/browse/QPID-8222
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-client-0-x-6.3.0, qpid-java-6.1.5, qpid-java-client-0-x-6.3.1,
> qpid-java-client-0-x-6.3.2
>Reporter: Alex Rudyy
>Priority: Blocker
> Fix For: qpid-java-client-0-x-6.3.3
>
> Attachments: thread-dump.txt
>
>
> JMS transaction commit/rollback or recover can hang when connectivity is lost
> and failover is triggered to restore the connection. When
> commit/rollback/recover are invoked after restoring the connectivity and
> before failover finishes resubscribing of existing sessions, the syncing of
> dispatcher queue can hang due to race with adding the signal message into the
> queue from session operation and cleaning the queue by failover. Here is a
> dump of hang commit operation:
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x0241c000 nid=0x2e18 waiting on
> condition [0x02a9f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00076d9f4c70> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2343)
> at org.apache.qpid.client.AMQSession.rollback(AMQSession.java:1984)
> - locked <0x00076d67e5f8> (a java.lang.Object)
> at org.apache.qpid.client.AMQSession.commit(AMQSession.java:922)
> at org.apache.qpid.test.Test.main(Test.java:40)
> {noformat}
> The defect was introduced as part of changes committed against QPID-3521. I
> do not see any sensible work around for the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8228) [JMS AMQP 0-x] Release Qpid JMS AMQP 0-x 6.3.3
[ https://issues.apache.org/jira/browse/QPID-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy closed QPID-8228. Resolution: Fixed > [JMS AMQP 0-x] Release Qpid JMS AMQP 0-x 6.3.3 > -- > > Key: QPID-8228 > URL: https://issues.apache.org/jira/browse/QPID-8228 > Project: Qpid > Issue Type: Task > Components: JMS AMQP 0-x >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-client-0-x-6.3.3 > > > Release Qpid JMS AMQP 0-x client following instructions > [here|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid JMS AMQP 0-x 6.3.3 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS AMQP 0-x 6.3.3. This is the latest release of our legacy JMS client supporting AMQP 0-8, 0-9, 0-9-1 and 0-10. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-jms-amqp-0-x-6.3.3/release-notes.html The Apache Qpid community strongly suggests to use our new JMS client (http://qpid.apache.org/components/jms/index.html) supporting AMQP 1.0 for development of new applications. Thanks to all involved, Alex - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585682#comment-16585682
]
Robbie Gemmell commented on QPIDJMS-409:
You have closed this as Cannot Reproduce but originally noted your jobs quickly
tripped up previously. Were you unable to get further occurrences with the same
code, or were you using different code and/or able to identify some other
specific issue that could have caused it?
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
> Attachments: successful_delayed_delivery.txt
>
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
> {{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
> jmsMessage) -> {}}
> {{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{ return jmsMessage;}}
> {{});}}
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Description:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
message with an illegally encoded _properties_ section..
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primitive type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
was:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primitive type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] ->
