qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: State of C++ 0-9 branch
Date Tue, 09 Jan 2007 13:51:22 GMT
I the meantime here is a patch that works around the problem for the
branch. (apply in cpp directory).

Andrew


On Tue, 2007-01-09 at 08:45 -0500, Carl Trieloff wrote:
> 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
View raw message