Re: Oneway Call Dies in ORBit2

[Michael Meeks <michael ximian com>]

Hi Donna,

On Thu, 2004-02-19 at 18:26, lgust@verizon.net wrote:
> We need help with a problem we found in ORBit2 while integrating our software.
> My co-worker, Donna, describes how ORBit2 stops transmitting data on a oneway call:

	Ok; so you've got a lot closer to what is going on; thanks for the
great report.

> At this point, link_connection_writev() queues the data that was not
> written onto the connection's private write queue (cnx->priv->write_queue)
> and returns LINK_IO_QUEUED_DATA to its caller, which indicates everything
> is OK.   From then on link_connection_writev() never calls write_data_T(
>  again, because the connection's private write queue is never cleared.
> link_connection_writev() keeps returning LINK_IO_QUEUED_DATA to its
> caller, indicating everything is OK.  At this point, the application
> is still working (just not sending data), the application's memory
> usage begins to go up very quickly, and it never recovers.

	Right - so the problem is - we never start polling for the POLLOUT
condition - which is set when there would be space available for us to
write data to that socket. However when we call:

> ------------------Note code between marks---------------------
> 		if (link_thread_safe ()) {
> 			queue_flattened_T_R (cnx, qw.vecs, qw.nvecs, TRUE);

	The 'TRUE' here _should_ cause queue_flattened_T_R to update the poll
(for IO_OUT) in the I/O thread, with this code:

---  cut  ---
	new_queue = cnx->priv->write_queue == NULL;
	cnx->priv->write_queue = g_list_append (cnx->priv->write_queue, qw);
	queue_signal_T_R (cnx, total_size);

	if (update_poll && new_queue) {
		LinkCommandSetCondition *cmd;

		cmd = g_new (LinkCommandSetCondition, 1);
		cmd->cmd.type = LINK_COMMAND_SET_CONDITION;
		cmd->cnx = link_connection_ref_T (cnx);
		cmd->condition = (LINK_ERR_CONDS | LINK_IN_CONDS | G_IO_OUT);
		link_exec_command (&cmd->cmd);
	}
---  cut  ---

	So - we _should_ see that command executed in
(link_connection_exec_set_condition), which will set the G_IO_OUT
condition on the poll; which _should_ result in us getting a G_IO_OUT
poll request in the (link_connection_io_handler) which _should_ result
in 


---  cut ---
	if (cnx->status == LINK_CONNECTED && condition & G_IO_OUT) {
		d_printf ("IO Out - buffer space free ...\n");
		link_connection_flush_write_queue_T_R (cnx);
	}
--- cut ---

	So - we should get some writeout there.

	So - really; the punch-line is; enable the link debug: linc-debug.h
#define CONNECTION_DEBUG [ if you can on your machine ], and we'll
examine the output (most of the paths have strings in them).

	Also - sending oneways is intrinsically risky in this way - if the
connection goes slower than the rate of event emission you fill up your
memory with a queue. There is a process to fix this - if you use:

ORBitConnection      *ORBit_small_get_connection_ref   
(CORBA_Object     obj);
void                  ORBit_small_connection_unref      (ORBitConnection
*cnx);
void                  ORBit_connection_set_max_buffer   (ORBitConnection
*cnx,
							 gulong           max_buffer_bytes);

	and 

ORBitConnectionStatus ORBit_small_listen_for_broken        (CORBA_Object
obj,
							    GCallback    fn,
							    gpointer     user_data);
ORBitConnectionStatus ORBit_small_unlisten_for_broken_full (CORBA_Object
obj,
							    GCallback    fn,
							    gpointer     user_data);

	Then you can set a limit on the buffer, and get a disconnect signal at
that point.

	HTH, sorry for the delay,

	Regards,

		Michael.

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