axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Reinshagen_C <>
Subject RE: Parsing stuff
Date Thu, 19 Apr 2001 22:59:09 GMT
My understanding (which could be mistaken) 
from both the docs on weblogic and the J2EE
spec was that applications running inside
a container were not allowed to create threads,
but must call on the services of the container 
to do this.  

I believe (but I'm not sure) that one of problems
when doing this in weblogic is that the container
may choose to insert data into Threadlocal on the
current thread, which could cause memory leaks
if these are your own threads, because the
container is not aware of these threads.

In weblogic this is accomplished via
their Schedulable, Triggerable interfaces.

The following is from a BEA newgroup posting...

>> Forum:
>> Thread: Startup class - Unusual user identity 
>> Message 4 of 9

Subject: Re: Startup class - Unusual user identity 
Date: 04/06/2000 
Author: Bryan O'Sullivan <> 

>>The network communications functionality was running great until we
tightened the ejb 
>>security.(removing guest) The network comm 
>>startup class creates a number of classes, one of which spawns a number of
You should probably not be doing this.  We don't support applications that
create their own threads.  If you need to perform work asynchronously, look
into using our time and event services instead, in which case you can
schedule work to be performed by regular WebLogic execute threads.


-----Original Message-----
From: Erik Onnen []
Sent: Thursday, April 19, 2001 8:05 AM
To: ''
Subject: RE: Parsing stuff

I was wondering the same thing myself. My understanding is that it is OK to
use threads that operate in an app server _outside_ the context of an EJB.
In other words, if your app server is also your web server, it is Ok to use
threading in the servlets, for example something like soap message routing.
But, I wonder how a multithreaded parser would respond inside the context of
an EJB. Most curious to hear the resolution.

-----Original Message-----
From: Sanjiva Weerawarana []
Sent: Thursday, April 19, 2001 10:59 AM
Subject: Re: Parsing stuff

Aren't there major issues with app servers and thread management? I
thought that part of the server side programming model was that
user application components are not spsed to be creating threads ..
the app server does thread creation and mgmt.

I believe Xalan does something like this with DTM. I wonder how they
addressed this issue.


----- Original Message -----
From: "Glen Daniels" <>
To: <>
Sent: Wednesday, April 18, 2001 7:15 PM
Subject: Parsing stuff

> I've got a version of the multi-thread SAX parse working, though it needs
> bit of cleanup.  It's mostly a proof-of-concept.
> I'm going to see if I can make some improvements, clean it up a bit, and
> post it to the list tomorrow for review.
> Basically, it does exactly what we talked about.  When you create a
> around an InputSource, it spawns a thread which parses the <envelope>
> element, makes sure it looks OK, and then suspends.  When anyone asks for
> something from the Message (i.e. getHeaderByName(QName)), the parsing
> wakes up and runs until it finds the desired thing or runs out of XML
> (initially this just means getting to the end of the headers).  As it
> it creates SOAPHeader objects, which contain records of the SAX events
> inside them, suitable for replaying to any ContentHandler.  Meanwhile the
> other thread (the one that made the getHeaderByName() call) blocks until
> parse is complete.
> Glen Daniels
> Macromedia
> Engineering Manager
>                                 Building cool stuff for web developers

View raw message