[Asterisk-Dev] Re: New h.323 channel driver

[Paul Cadach]

Hello,

Craig Southeren wrote:
> On Wed, 11 May 2005 15:53:38 +0300
> Michael Manousos <manousos at inaccessnetworks.com> wrote:
> > > The problems mostly relies on OpenH323 - there is deadlock condition, check #3967. Also, under high load single
cleaner
> >
> > I have also notice them, but only with the Pandora or above versions.
> > That's the main reason that asterisk-oh323 has stuck with the Janus
> > version of OpenH323/Pwlib.
> >
> > > thread isn't able to cleanup calls as needed, and some sort of workaround is required (e.g., move some
time-consuming
> > > cleanup code into H323Connection::ClearCall instance).
>
> In my past experience, these kinds of problems with OpenH323
> applications have been caused by subtle race conditions in the
> application code associated with call shutdown.

You're right. 90% of all existing problems caused by application design and OS-specific "features". OpenH323 itself is
very solid and mostly stable for basic call handling, when application is native OpenH323. But for Asterisk there is
many problems caused chan_h323/chan_oh323/etc. isn't native OpenH323 application.

> I've not seen any problems in the OpenH323 cleanup thread for many years.
> That code has been tested and reviewed sixteen different ways from zero,
> and I know of many companies who use OpenH323 for 100+ simultaneous
> calls with application run-times measured in months without any problems

Just try to run callgen323 to callgen323 with tracing on both ends under VMware, where context switches is much more
costly than under real CPU. You can easily get very high CPU load (15-30 on about 20-50 simultaneous calls), then you
will raise all sort of misoperations the library and an application.

Probably cleaner thread problems caused by verbose tracing used to debug threads/VMware/etc only. Cleanup thread is
single thread while call handling uses much more threads and therefore have most of CPU time used by call handling. On
call cleanup there is one time-consuming place when cleaner thread terminates H.245 thread and waits up to 10 seconds
for exhanging of final messages. Under high load and slow context switches list of calls to be cleaned enlarges too
much, application eats all available file descriptors and being to have problems.


WBR,
Paul.