qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: State of C++ 0-9 branch
Date Tue, 09 Jan 2007 13:45:48 GMT

The issues is that there no one easy way to pass the version from 
ProtocolInitiation to the
Frame class. I have a few options that I have being working on but none 
that I am
willing to commit yet the full set.

If you set it to 0-9 for now hard coded I will check in a new version of 
framing this morning that
fixes this issue, and I will hard code the call path to 
highestProtocolVersion until I have tested
the larger changes. highestProtocolVersion is generated so that will 
clean it up for now.

Carl.


Kim van der Riet wrote:
> Carl is currently working on this... (see the JIRA QPID-124). He is
> linking the version obtained from the session's ProtocolInitiation to
> all places in the code where a version is required. In the meantime, it
> should be an easy task to find all places where 0-8 (major=8, minor=0)
> is used, and replace it with 0-9 (major=0, minor=9). (Recall, we changed
> the way a version is represented i.t.o. major and minor from 0-8 to
> 0-9.)
>
> It seems that the core is occurring in the MethodVersionMap, where a
> non-existent version is being sought. It seems a little more graceful
> termination should be put in here - a ProtocolVersionException should be
> thrown where the map does not contain the required combination of class
> and method ID and version (line 150) - so how does this end in a core?
>
> Kim
>
> On Tue, 2007-01-09 at 11:41 +0000, Andrew Stitcher wrote:
>   
>> Alan,
>>
>> Oh well when I saw this problem yesterday I thought that I'd
>> misremembered what you said.
>>
>> I was looking at this yesterday, the issue is this line in
>> cpp/lib/framing/AMQFrame.cpp:71;
>>
>> // AMQP version management change - kpvdr 2006-11-16
>> // TODO: Make this class version-aware and link these hard-wired numbers
>> to that version
>> AMQBody::shared_ptr body(versionMap.createMethodBody(classId, methodId,
>> 8, 0));
>> // Origianl stmt:
>> // AMQBody::shared_ptr body(createAMQMethodBody(classId, methodId));
>>
>> which explicitly creates an 8-0 type frame body.
>>
>> What I don't currently understand is why this is only crashing the
>> client, not the broker as well (it's in the framing code). I assume the
>> sequence is something like client does 0.9 open connection negotiation
>> (which doesn't use actual protocaol frames). Broker replies with 0.9
>> frame and then the client dies as it makes a 8.0 frame as above. Ah I
>> seem to have answered my own question!
>>
>> More general Q: Do we have a wire level protocol decoder? I.E something
>> to plugin into tcpdump or similar? It would be quite handy to debug more
>> complex versions of problems like this. If not I guess I'll add it to
>> Jira.
>>
>> On Mon, 2007-01-08 at 21:56 -0500, Alan Conway wrote:
>>     
>>> I *thought* the client_test was passing on the 0-9 branch this morning,
>>> but it looks like I was halucinating and/or using the wrong working
>>> copy. It's coring at:
>>>
>>> #1 0x0018a291 in
>>>     qpid::framing::AMQP_MethodVersionMap::createMethodBody (
>>>     this=0x1c6c80, classId=10, methodId=10, major=8 '\b', minor=0
>>>     '\0') at ./../../gen/AMQP_MethodVersionMap.cpp:150
>>>
>>> Kim - it looks like some code is picking up the version from XML but
>>> some has it hard-wired. Do you know which/how many classes still have
>>> the hard-wired version numbers? I can fix it on the  0-9 branch, I'm
>>> just checking if there's anything special problem that I should be aware
>>> of.
>>>
>>> Cheers,
>>> Alan.
>>>
>>>       
>
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message