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

Jiri Daněk commented on PROTON-2451:
------------------------------------

[~astitcher] The last comment broke Dispatch tests. Dispatch asserts on 
protocol trace logs, and those have changed in small but significant ways. For 
example, in this instance the number format has changed from decimal to hex

{noformat}
>           self.assertIn(" channel-max=32767", open_lines[0])
E           AssertionError: ' channel-max=32767' not found in '2021-11-04 
22:44:06.747987 +0000 PROTOCOL (trace) [C2]:FRAME: 0 -> @open(16) 
[container-id="QDR", hostname=null, max-frame-size=0x4000, channel-max=0x7fff, 
idle-time-out=0xea60, outgoing-locales=null, incoming-locales=null, 
offered-capabilities=@<symbol>[:ANONYMOUS-RELAY, :"qd.streaming-links"], 
desired-capabilities=@<symbol>[:ANONYMOUS-RELAY, :"qd.streaming-links"], 
properties={:product="qpid-dispatch-router", :version="1.19.0-SNAPSHOT", 
:"qd.conn-id"=2}] 
(/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:111)'
{noformat}

https://github.com/apache/qpid-dispatch/runs/4111309822?check_suite_focus=true#step:27:313

CC [~gmurthy]

> Reduce (ultimately eliminate) all use of the pn_data_t data structure in AMQP 
> frame processing
> ----------------------------------------------------------------------------------------------
>
>                 Key: PROTON-2451
>                 URL: https://issues.apache.org/jira/browse/PROTON-2451
>             Project: Qpid Proton
>          Issue Type: Improvement
>          Components: proton-c
>            Reporter: Andrew Stitcher
>            Assignee: Andrew Stitcher
>            Priority: Major
>             Fix For: proton-c-0.37.0
>
>
> In current proton protocol processing code make heavy use of the pn_data_t 
> data structure for coding and decoding AMQP frames to send and receive. 
> Unfortunately the data structure is complex and the code which uses it is not 
> very efficient. This means that a lot of CPU is consumed maniputing these 
> data structures unnecessarily during the critical path operations of proton. 
> During frame processing pn_data_t is not even really necessary as it is only 
> used as an intermediary to extract necessary frame parameters out of the 
> frames (or as an intermediary to construct the frames from the necessary 
> frame parameters.
> This means that is entirely feasible to go directly from/to the parameters 
> to/from the frames without using an intermediate pn_data_t at all.
> The most complicated aspect of this and one which will be deferred somewhat 
> is that of using non scalar structured data as part of AMQP frames.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to