Forums

by Torrie >> Sat, 22 Nov 2003 15:15:45 GMT

I've got a process perfoming a continuous listen on a TCP/IP port. When a new connection arrives it passes the connection to an existing worker process that reads the message and processes it. Once the worker has finished it fires a notification on the listener process to tell it that it is free again. If there are no workers then the messages are added to a queue and delt with when a worker reconnects.

After looking at the logs it appeared that I received lots of new connections but no notifications from the workers that were started. Does anyone know if Jade will run the call back method for a new connection even if notifications that are yet to be processed have been received, or if the new connections and notifications are delt with in the same queue?

Thanks

Torrie

by allistar >> Mon, 24 Nov 2003 5:45:20 GMT

Hi Torrie,
I don't know for sure but I would say that the callback event gets stuck in the queue like any other event.

A way around this is to change your design slightly so you maintain a collection of all workers and of available workers. As long as the workers are shared transients you can then get the worker to remove itslef from the available collection when it starts working, and add itself back into the available collection when it has finised its task. This way you don't need to use a notification when a worker has finished. All the listener process need to do is get the allAvailableWorkers.first() worker instance (and queue the request if this is null).

Hope this helps,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

by Torrie >> Mon, 24 Nov 2003 13:41:25 GMT

I delibrately not used a shared collection of workers, as I thought that the contention on the collection could be a problem in times of high demand. I have contacted Jade support to see if they can answer this but may need to revisit my design.

It has been suggested that I use locks to determine which workers are in use (the worker locks itself when it is busy.) This would also remove the need for notifications when the worker is idle and the collection of idle workers.

Torrie

by allistar >> Mon, 24 Nov 2003 19:41:19 GMT

Hi Torrie,
A model I have used for this sort of thing is to have a listener process (that waits for TCP/IP requests), a queuer process (the is responsible solely for managing the worker threads, which remobing contention issues on the worker collection) and the workers themselves.

Splitting the role of the listener into a separate listener and queuer will alleviate contention issues under high load. I would communicate between the processes with notificaions (causeEvent). The listener would not receiver any notifications, and the only events it would process would be the connection callback. This design alleviates you event ordering issue as posed in the initial question. Basically the listener doesn't care about how many workers are available, that is the job of the queuer.

That has worked for me, anyway. Your mileage may vary.

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

by Torrie >> Tue, 25 Nov 2003 8:37:13 GMT

For your information from Jade Support.

===================================

The thread that is started to handle the TcpIpConnection.listenContinuousAsynch when it receives a new connection uses the same technique to pass control back to the relevant application thread as is used for notification delivery.

eg: In the case of a system running under Win32, both the callBack and the notifications are posted to the Windows Message Queue.

These are processed in a FIFO manner, so notifications that were posted to the queue prior to a callBack message will get delivered prior to the callBack message being delivered.

There is one caveat on this, in that currently notification delivery is deferred when a process is in exception state while callBack messages are still processed while in exception state - we have an NFS open already suggesting it would be nice for callBacks to be deferred like notifications when in exception state.