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.
