RE: Xalan2 in server environment (was Xalan2 Stree Module spans sec ondthread to do transform?)
Thanks, Scott.
I doubt it does the trick generally for EJB, but it does the trick for our
app server :-)
EJB is unkind to threaded algorithms to the point that I see this as a major
hole in EJB, though I suppose you could hide this in a Connector and
potentially skirt some of the restrictions
Still, there *are* algorithms which should be threaded and EJB shouldn't
make it a supreme pain to do this!
--
Jess Holle
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 09, 2001 2:51 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Xalan2 in server environment (was Xalan2 Stree Module spans
sec ondthread to do transform?)
In response to this I've created the following method in
org.apache.xalan.TransformerImpl:
/**
* Create a thread for the transform. This can be overridden by derived
* implementations to provide their own thread, for thread pooling and
the
* like.
*
* @return thread suitable to use for the transformation.
*/
public Thread createTransformThread()
{
return new Thread(this);
}
Someone who is using XalanJ2 in an EJB environment or the like can set the
javax.xml.transform.TransformerFactory system property to provide a
derivation from TransformerImpl, and provide a thread suitable for the
environment.
I don't know if this will do the trick. Please advise.
-scott
"Roytman,
Alex" To:
"'[EMAIL PROTECTED]'" [EMAIL PROTECTED]
roytmana@peaccc:
"'[EMAIL PROTECTED]'"
etech.com[EMAIL PROTECTED],
(bcc: Scott Boag/CAM/Lotus)
Subject: Xalan2 in server
environment (was Xalan2 Stree Module spans
01/07/2001sec ond thread to do transform?)
12:14 AM
Please respond
to xalan-dev
Scott,
Thank you very much for your reply.
One part which is sensitive to thread origin in my opinion is Extensions
In extensions people can do all sorts of things. I am not very experienced
with EJB implementation but I can imagine that many things (transactional
context, bean environment, etc.) depend on threads and some static
variables
which helps with setting /switching context for beans being managed by the
server.
Example: in J2EE it is recommended to create JNDI initial context using
default constructor InitialContext(). The result of the instantiation
depends on the context where it was executed and the context is set by the
server for the thread on which your component is running. So if you call
new
InitialContext() in your extension (in sql extension to get JDBC DataSource
for example ) it might fail.
Do extension run on the second (created by Xalan) thread?
I will forward your message to Tomcat news group lets see what Tomcat
developers think.
Alex
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 06, 2001 11:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Xalan2 Stree Module spans second thread to do transform?
In many
cases component should not attempt to create its own threads.
For example thread's ContextClassLoader or ThreadLocal variables might
need
to be initialized by the server.
Also it defeats thread pooling done by the server etc.
Could you please comment on this issue
Yeah, I've been a bit worried about this. However, I've not yet heard of
any problems that have been caused by it, and XalanJ1 has long had a two
threaded system (though not as effective as in XalanJ2). Ultimately, I
would rather use a pull model for this, and only have one thread, but a)
there is no standard "pull" API for XML parsers, and b) this doesn't work
anyway when SAX events are used, for whatever reason.
I'm open to any input to how Xalan might request the thread from the
servlet environment, though it has to be able to be run outside a servlet
environment too. Also, it would be good if someone with deep knowledge of
EJB's and the like could comment. I talked this over in a hallway
conversation with someone who is fairly familiar with EJB's, and he didn't
think there was a problem, though I forget why. It seems insane/crazy to
me that a component can't use a thread in it's internal modules.
-scott
"Roytman,
Alex" To:
"'[EMAIL PROTECTED]'" [EMAIL PROTECTED]
roytmana@peaccc: (bcc: Scott
Boag/CAM/Lotus)
etech.comSubject: Xalan2 Stree Module
spans second thread to do transform?
01/06/2001
10:48 PM
Please respond
to xalan-dev
Dear Xalan developers,
I have a question about using upcoming Xalan2 in server env.
In Xalan2 design specs it is said:
"The Stree module implements the default Source Tree
Re: Xalan2 in server environment (was Xalan2 Stree Module spans sec ondthread to do transform?)
In response to this I've created the following method in
org.apache.xalan.TransformerImpl:
/**
* Create a thread for the transform. This can be overridden by derived
* implementations to provide their own thread, for thread pooling and
the
* like.
*
* @return thread suitable to use for the transformation.
*/
public Thread createTransformThread()
{
return new Thread(this);
}
Someone who is using XalanJ2 in an EJB environment or the like can set the
javax.xml.transform.TransformerFactory system property to provide a
derivation from TransformerImpl, and provide a thread suitable for the
environment.
I don't know if this will do the trick. Please advise.
-scott
"Roytman,
Alex" To: "'[EMAIL PROTECTED]'"
[EMAIL PROTECTED]
roytmana@peaccc: "'[EMAIL PROTECTED]'"
etech.com[EMAIL PROTECTED], (bcc:
Scott Boag/CAM/Lotus)
Subject: Xalan2 in server environment
(was Xalan2 Stree Module spans
01/07/2001sec ond thread to do transform?)
12:14 AM
Please respond
to xalan-dev
Scott,
Thank you very much for your reply.
One part which is sensitive to thread origin in my opinion is Extensions
In extensions people can do all sorts of things. I am not very experienced
with EJB implementation but I can imagine that many things (transactional
context, bean environment, etc.) depend on threads and some static
variables
which helps with setting /switching context for beans being managed by the
server.
Example: in J2EE it is recommended to create JNDI initial context using
default constructor InitialContext(). The result of the instantiation
depends on the context where it was executed and the context is set by the
server for the thread on which your component is running. So if you call
new
InitialContext() in your extension (in sql extension to get JDBC DataSource
for example ) it might fail.
Do extension run on the second (created by Xalan) thread?
I will forward your message to Tomcat news group lets see what Tomcat
developers think.
Alex
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 06, 2001 11:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Xalan2 Stree Module spans second thread to do transform?
In many
cases component should not attempt to create its own threads.
For example thread's ContextClassLoader or ThreadLocal variables might
need
to be initialized by the server.
Also it defeats thread pooling done by the server etc.
Could you please comment on this issue
Yeah, I've been a bit worried about this. However, I've not yet heard of
any problems that have been caused by it, and XalanJ1 has long had a two
threaded system (though not as effective as in XalanJ2). Ultimately, I
would rather use a pull model for this, and only have one thread, but a)
there is no standard "pull" API for XML parsers, and b) this doesn't work
anyway when SAX events are used, for whatever reason.
I'm open to any input to how Xalan might request the thread from the
servlet environment, though it has to be able to be run outside a servlet
environment too. Also, it would be good if someone with deep knowledge of
EJB's and the like could comment. I talked this over in a hallway
conversation with someone who is fairly familiar with EJB's, and he didn't
think there was a problem, though I forget why. It seems insane/crazy to
me that a component can't use a thread in it's internal modules.
-scott
"Roytman,
Alex" To:
"'[EMAIL PROTECTED]'" [EMAIL PROTECTED]
roytmana@peaccc: (bcc: Scott
Boag/CAM/Lotus)
etech.comSubject: Xalan2 Stree Module
spans second thread to do transform?
01/06/2001
10:48 PM
Please respond
to xalan-dev
Dear Xalan developers,
I have a question about using
Re: Xalan2 in server environment (was Xalan2 Stree Module spans sec ondthread to do transform?)
[EMAIL PROTECTED] wrote: "Roytman, Alex" [EMAIL PROTECTED] wrote: One part which is sensitive to thread origin in my opinion is Extensions In extensions people can do all sorts of things. Yep, I can see that. It sounds like we should at least provide a property to turn off the threading, which we should probably do in any case. I'm not sure I can do this in time for our upcoming 2.0 release, as it feels a little destabilizing, but let me sleep on it. In Tomcat 4.0 we implement the JNDI naming context stuff so that you can call "new InitialContext()" and get the context that is relevant for your webapp. This relies on the thread having been initialized correctly by the container. It sounds like "extension" might be problematic. There are also restrictions on the time when it is valid for an application level thread to reference the request and response objects that are handed to the service() method. Basically, after service() returns those object instances are off limits, so you also need to ensure that any threads you create do not maintain any live references to the request and response outside the safe time interval. The best solution for this is to have some sort of discoverable interface for Xalan to create threads with. You would think that the EJB stuff could somehow override thread construction globally, so this stuff would all be hidden. But I'm sure there are good reasons it can not. While it might be possible to create such an interface in a servlet container, my understanding is that EJBs are prohibited from creating new threads (and, in many app servers, will be actively prohibited from doing so by the security manager that the bean code runs under). Do extension run on the second (created by Xalan) thread? Yes. The main thread is the parser event thread. The second thread, which I call the transform thread, performs the transformation, executing extensions as it goes, and sends parse events to the Result interface, which is probably a serializer. If the main thread finishes before the transform thread, it 'joins' with the transform thread. If you chain several Transformers or XMLReaders together you get another thread for each pipe. This is good and bad, since the number of threads increases, but the pipeline tends to keep moving along... pipe number three can be getting bytes to the wire while pipe number 1 is just getting started. The transform thread's run method is to be found in org.apache.xalan.transformer.TransformerImpl#run(), and the thread is created in org.apache.xalan.stree.SourceTreeHandler#startDocument(), and does the join in org.apache.xalan.stree.SourceTreeHandler#endDocument(). If you are using a DOM as the source, you are not running the second thread... this only happens when Xalan can create it's own source tree. -scott Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Xalan2 in server environment (was Xalan2 Stree Module spans sec ondthread to do transform?)
"Roytman, Alex" [EMAIL PROTECTED] wrote: One part which is sensitive to thread origin in my opinion is Extensions In extensions people can do all sorts of things. Yep, I can see that. It sounds like we should at least provide a property to turn off the threading, which we should probably do in any case. I'm not sure I can do this in time for our upcoming 2.0 release, as it feels a little destabilizing, but let me sleep on it. The best solution for this is to have some sort of discoverable interface for Xalan to create threads with. You would think that the EJB stuff could somehow override thread construction globally, so this stuff would all be hidden. But I'm sure there are good reasons it can not. Do extension run on the second (created by Xalan) thread? Yes. The main thread is the parser event thread. The second thread, which I call the transform thread, performs the transformation, executing extensions as it goes, and sends parse events to the Result interface, which is probably a serializer. If the main thread finishes before the transform thread, it 'joins' with the transform thread. If you chain several Transformers or XMLReaders together you get another thread for each pipe. This is good and bad, since the number of threads increases, but the pipeline tends to keep moving along... pipe number three can be getting bytes to the wire while pipe number 1 is just getting started. The transform thread's run method is to be found in org.apache.xalan.transformer.TransformerImpl#run(), and the thread is created in org.apache.xalan.stree.SourceTreeHandler#startDocument(), and does the join in org.apache.xalan.stree.SourceTreeHandler#endDocument(). If you are using a DOM as the source, you are not running the second thread... this only happens when Xalan can create it's own source tree. -scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
