[omniORB] LocateRequest gets dropped on RHEL 6.1 system
duncan at grisby.org
Thu Sep 29 13:56:26 BST 2011
On Fri, 2011-09-23 at 16:07 -0500, Brad Fawcett wrote:
> inserted a memset of 0x right before tcp::recv call. for the bad
> call, the buffer remains
> all zero's. so, it looks like no data is being transferred.
That seemed like the most likely situation.
> but the curious thing is that it is so darn consistent with
> relationship to the CORBA calls.
> It is always on the 23rd corba call of this testcase. & is not
> dependent upon timing between
> CORBA requests. & if is a pure tcp/OS bug, then wouldn't it be
> appearing more often in other cases?
That is odd that it is so consistent. The only think I can think of is
that it's something to do with the volume of data transferred up to that
point, but adding up the numbers of bytes in each message, none of the
numbers look like obvious boundaries.
> can u think of anything from the corba side of things that would
> happen that might interrupt a tcp::recv before it completes
> successfully? does it do many peeks? or selects? or something like
> that? are the any trace points you would suggest inserting to see
> what is happening during this time?
The only other thing that might be going on at the time is a "select"
thread that watches connections for activity. That could potentially be
doing poll() on the same socket as the thread doing recv(). You could
add a log message before and after the call to poll() at line 507 in
src/lib/omniORB/orbcore/SocketCollection.cc. If that indicates that a
poll() is happening at the same time as the recv(), that might be it. On
the other hand, I wouldn't expect it to be consistent enough in its
timing that it always clobbered the 23rd call if it was something to do
Other than that, omniORB's usage of sockets is really quite simple. I
can't think of anything that would be significantly different from other
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list