Re: Oneway Call Dies in ORBit2

[Michael Meeks <michael ximian com>]

Hi Donna,

On Wed, 2004-03-03 at 12:56 -0800, Donna J Witt wrote:
> Thank you for getting back to me on this issue.   I modified link_debug.h
> to turn on debugging so that you can look at the output.

	Great.

>   Also, I added the
> printf "write_data_T(): returning LINK_IO_QUEUED_DATA ################" so
> that I could easily find the place I wanted to start examining the output.

	That's most helpful.

> rtrn5.txt shows things working fine, the write problem occuring, and the
> queuing continues.  The poll is updated as you expected, but the
> link_connection_io_handler never gets called on with the G_IO_OUT poll
> request.

	This is very odd. Is it possible that the IO thread has deadlocked
somehow ? what does a stack trace of all the threads look like (thread
apply all backtrace) in gdb (if you can get that?). The I/O thread
should be blocked in a poll call. [ this is assuming you're using the
ORB with an I/O thread - ( to do that you need to use some exotic
policy ) ].

	_Perhaps_ the problem is - you are not using an I/O thread and doing
something like:

	while (1) {
		send_oneway_message ();
		usleep (100);
	};

	Which would have the effect you report (without the I/O thread) - since
we queue the data for writing, but then never hit the linc mainloop in
order to attempt to re-send the data later.

	If that's the case, you really need to be using the I/O thread (or a
glib main context to do the delay). To force the I/O thread issue, you
can create a POA and assign a threaded policy cf. ORBit2/src/orb/poa/
orbit-adaptor.c (ORBit_ObjectAdapator_set_thread_hintv).

>    Once I saw the queuing begin, I let the applications run for a
> short time before stopping them.  When I stopped the applications, no data
> is going across the CORBA interface at all.   All of this is in rtrn5.txt.

	Right - it seems it never hits the poll.

> Nothing actually went
> across the interface, because the writev() function is not being called and
> the data is still being queued.   You can see that the number of bytes on
> the "queue signal" continues to grow.

	Right.

> Can you explain to me where the G_IO_OUT signal is supposed to come from?
> And how the link_connection_io_handler is supposed to get called?

	Well - G_IO_OUT is a poll return value; ultimately as long as there is
any space available to write to on that socket, a poll with G_IO_OUT
will immediately return with that flag set, and we will write stuff. So
- clearly that poll is never getting run.

> Is there an assumption that the writev() system call failed because there
> was no space available to write data to the socket?

	In fact the exact cause of that shouldn't much matter.

	Regards,

		Michael.

-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot