Earlier I reported a very gradual slowdown in the performance
of my simple 1-sender 1-receiver test, on RHEL 7.0 and Fedora 20
but not on RHEL 6.3 .
The slowdown caused the test to end up running at half speed after
a billion or two billion messages. ( Which took hours to run. )
I now know
On 27. 10. 14 09:10, Michael Goulish wrote:
Earlier I reported a very gradual slowdown in the performance
of my simple 1-sender 1-receiver test, on RHEL 7.0 and Fedora 20
but not on RHEL 6.3 .
The slowdown caused the test to end up running at half speed after
a billion or two billion
You know, I thought of something along those lines, but I can't
see how it makes the receiver actually use less CPU permanently.
It seems like it ought to simply get a backlog, but go back
to normal CPU usage.
Can you think of any way that a backlog would cause receiver to
stay at low CPU?
Hi Michael,
That sounds very much like the root of the issue. If the signal handler is
triggered from inside a current call then the engine will be in an
inconsistent state when any calls from inside the signal handler are made.
This is quite likely what is causing the sequence ids to get out of
Gordon Sim created PROTON-730:
-
Summary: Can't read transactional state set on incoming transfer
Key: PROTON-730
URL: https://issues.apache.org/jira/browse/PROTON-730
Project: Qpid Proton
Issue
Given the involvement of reentrance due to signal handlers, I'm satisfied
with saying that unless there is more information we don't have a proton
bug causing the out-of-sequence ids. However given the abort that occurs on
the server side when proton receives the out-of-sequence ids I'm inclined
[
https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185228#comment-14185228
]
Gordon Sim commented on PROTON-730:
---
This is the other side of PROTON-667 really, where
[
https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-723:
--
Attachment: PROTON-723_part2_quick_and_dirty.patch
This patch is for the other side of the wire,
[
https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-730:
--
Attachment: PROTON-730_quick_and_dirty.patch
Quick and dirty fix. This follows the same approach
[
https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-730:
--
Priority: Critical (was: Major)
Can't read transactional state set on incoming transfer
[
https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185247#comment-14185247
]
ASF subversion and git services commented on PROTON-730:
Commit
[
https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185246#comment-14185246
]
ASF subversion and git services commented on PROTON-723:
Commit
When using messenger in non-blocking mode, it is possible to ensure that the
empty frame heartbeats are sent by calling pn_messenger_work(timeout) on a
regular interval (when no other send / recv operations are happening).
However, when using messenger in blocking mode it is not obvious how one
On 27. 10. 14 13:16, Michael Goulish wrote:
You know, I thought of something along those lines, but I can't
see how it makes the receiver actually use less CPU permanently.
It seems like it ought to simply get a backlog, but go back
to normal CPU usage.
My guess is that sender creates for
On 10/27/2014 04:39 PM, Bozo Dragojevic wrote:
On 27. 10. 14 13:16, Michael Goulish wrote:
You know, I thought of something along those lines, but I can't
see how it makes the receiver actually use less CPU permanently.
It seems like it ought to simply get a backlog, but go back
to normal CPU
If this turns out to be the problem then please file a JIRA for it. That
code is some of the oldest code in proton and there has been a nice
efficient circular buffer implementation available in the codebase for ages
now.
--Rafael
On Mon, Oct 27, 2014 at 1:35 PM, Gordon Sim g...@redhat.com
Darryl L. Pierce created PROTON-731:
---
Summary: Installing language bindings provides no means to
override the install path
Key: PROTON-731
URL: https://issues.apache.org/jira/browse/PROTON-731
Dominic Evans wrote
When using messenger in non-blocking mode, it is possible to ensure that
the empty frame heartbeats are sent by calling pn_messenger_work(timeout)
on a regular interval (when no other send / recv operations are
happening).
However, when using messenger in blocking mode
18 matches
Mail list logo
