Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 gsim@redhat.com)
Message-ID: <5531424F.2000909@redhat.com>
Date: Fri, 17 Apr 2015 18:26:39 +0100
From: Gordon Sim <gsim@redhat.com>
Organization: Red Hat UK Ltd, Registered in England and Wales under Company
 Registration No. 3798903, Directors: Michael Cunningham (USA), Matt Parsons
 (USA), Charlie Peters (USA), Michael O'Neill (Ireland)
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Framing error causes abort
References: 
 <CABcBkRZP-ExHCrngzmF8OGOCfyD8_sJ6-k5N98mHQtOvkCenVg@mail.gmail.com>
 <55311BDA.6040509@redhat.com>
In-Reply-To: <55311BDA.6040509@redhat.com>
Content-Type: multipart/mixed;
 boundary="------------040608080405030203000509"

--------------040608080405030203000509
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.


--------------040608080405030203000509
Content-Type: text/x-patch;
 name="qpid-6501-extra-info.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qpid-6501-extra-info.patch"

diff --git a/qpid/cpp/src/qpid/amqp_0_10/Connection.cpp b/qpid/cpp/src/qpid/amqp_0_10/Connection.cpp
index 866f980..a5d1dec 100644
--- a/qpid/cpp/src/qpid/amqp_0_10/Connection.cpp
+++ b/qpid/cpp/src/qpid/amqp_0_10/Connection.cpp
@@ -103,9 +103,9 @@ size_t  Connection::encode(char* buffer, size_t size) {
             workQueue.swap(frameQueue);  // Need to get any new frames into the work queue
         }
     }
-    assert(workQueue.empty() || workQueue.front().encodedSize() <= size);
+    //assert(workQueue.empty() || workQueue.front().encodedSize() <= size);
     if (!workQueue.empty() && workQueue.front().encodedSize() > size)
-        throw InternalErrorException(QPID_MSG("Frame too large for buffer."));
+        throw InternalErrorException(QPID_MSG("Frame too large for buffer: " << workQueue.front()));
     {
         Mutex::ScopedLock l(frameQueueLock);
         buffered -= encoded;


--------------040608080405030203000509
Content-Type: text/plain; charset=us-ascii


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
--------------040608080405030203000509--