On 04/17/2015 06:26 PM, Gordon Sim wrote:
On 04/17/2015 03:42 PM, Gordon Sim wrote:
On 04/15/2015 09:26 PM, Scott Nicol wrote:
Another abort(), this time due to a framing error:
[...]
Here's the line in Connection.cpp:
assert(workQueue.empty() || workQueue.front().encodedSize() <=
size);
if (!workQueue.empty() && workQueue.front().encodedSize() > size)
throw InternalErrorException(QPID_MSG("Frame too large for
buffer."));
This seems to indicate that the broker is trying to write a frame bigger
than the 65536 bytes of buffer it was given.
The only way at present I can think of that this might happen is in
sending out a very large management related message (where at present
there appears to be no logic to split content up into frames if needed).
The above is wrong. Management messages go through queues, and the
connections over which messages are then sent out do the necessary
fragmentation, so this is not the cause.
One other idea is that it could be an 0-10 'header' frame (which qpidd
does not at present fragment). So e.g. if adding a trace id to the
message headers pushed it over the limit. However that would only happen
if either the message had a very large amount of application properties
to begin with or if it went through an enormous number of different queues.
Do you know roughly how much you use the application properties?
If you are able to reproduce with the small patch attached applied, it
would give a little more information to hopefully suggest other areas to
look at.
I raised https://issues.apache.org/jira/browse/QPID-6501 to track this.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
