[ https://issues.apache.org/jira/browse/PROTON-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15944294#comment-15944294 ]
Alan Conway commented on PROTON-1408: ------------------------------------- How about we introduce an explicit `uintptr_t pn_sequence_hashcode(pn_sequence_t n)` For now it can use the implementation proposed above. It is very likely that a good hash function for sequence numbers is NOT the same as a good hash function for void* pointers, so an explicit hash function would give us a place to put a better algorithm if we ever get to that. I haven't found the culprit but different conversion sequences from int32_t via void*/uintptr_t could give different results. The C integer conversion rules for uintptr = int32 require sign extension, but casting int32 to void* and *then* assigning to uintptr would give a bit copy - which is almost certainly not the same if uintptr_t is 64 bits. So if we have slightly different code paths it could give inconsistent results. An explicit hash function that takes a pn_sequence_t will ensure there is only one way to do the conversion and is self-explanatory. > long-lived connections suffer large performance hit after many messages > ----------------------------------------------------------------------- > > Key: PROTON-1408 > URL: https://issues.apache.org/jira/browse/PROTON-1408 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Reporter: michael goulish > Assignee: Alan Conway > Attachments: jira_proton_1408_reproducer.tar.gz > > > In long-running soak tests, in which connections are never taken down, I am > seeing a sudden & severe performance degradation when the number of messages > over the connection reaches about 6.4 billion. > This is happening in tests with two senders, two receivers & one router > intermediating. > I have tried C libUV clients as well as CPP clients. Behavior is not > identical, but I see sudden performance drop, ie. 8x throughput decrease or > worse, in both cases. > Alan / Ted / Ken see an issue in use of improper comparison logic in > pn_do_disposition(), in transport.c . I am trying to prove this now. -- 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