[omniORB] problem running client as xsub under mod perl : zombies attack.

[David Michmerhuizen]

I apologize in advance for being stupid, or needy, or unwelcome, or any other
offense.  Please hear my awful tale of woe and pity me... 


I'm using omniorb 2.8 to do some development. The basic purpose is to provide
DB access / functions via corba to a widely distributed set of web processes. 
Please don't suggest I use a perl orb for the perl end, I have enough problems
as it is.   

I have an object in IDL, a nice little server not much more complicated that
the eg3_impl (boa), and a client class that I can link into various things. 
I've got it as an executable program which works just fine - the server is over
on another machine with the name server, and when I run a test client, the
object methods happen on the server just like I expect them to. 

I've also written a perl XSUB (binary extension) which uses the object, and the
test.pl designed to test the xsub works just fine end to end.  

I can use my XSUB in a bunch of web pages (not of my design) running normally,
and that seems to work as well.  

If the web server is reconfigured to use mod perl, I get zombie processes. 

I call CORBA::ORB_init in the object constructor, and orb->NP_destroy in the
object destructor.  I can see the object go out of scope, even in mod perl
(it's blessed, thanks for asking), and my diags tell me I did indeed call
NP_destroy.  

At that point the zombies appear, two of them which, I am told, belong (or
belonged) to the apache handler for the (perl) CGI script I ran.  The handler,
(an apache mod-perl construct), is the script all loaded in and ready to
receive requests - it is written so that it does not actually exit the perl
interpreter.

If I try to perform the same activity again, my object complains when loading
the .so, performs whatever methods I ask (I see the data in my server's log),
and then the NP_destroy call hangs.  I do not see additional zombies, but I
think execution is hosed wherever that NP_destroy call is.  I don't know if
it's in the original CGI handler or if the request is routed to another handler
(I suspect the former).  


These mod perl zombies, is, I am told, because there are processes out there
whose status codes have not been reaped.  I can't imagine why this would also
screw up the handler.  


*** What I'm looking for is fairly instant words of wisdom ("Yeah, I know what
that is").  If not, I'll just keep trying other avenues.  

Thanks for listening.




=====
Nothing is impossible to the man who does not have to do it himself.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com