• Post Reply Bookmark Topic Watch Topic
  • New Topic

ThreadLocal & Servlet - Store XML parser for reuse?  RSS feed

 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I�m revising a huge application that relies on XML over https to comunicate from the POS(Actually is a lottery terminal) with app server. In app server we have a Servlet that receives and processes the request. The servlet relies on http session to store parsers for each client. The implementation used is quite simple:


This works well, but as we have a very high load application with around 23.000 terminals connected working all day, we have a huge amount of memory used to store the parsers for each client.
Our application server is tuned to have only 40 worker threads per instance. So I�d like to store our parser object(ExecutorXML) on the local threads for the server, so I would have maximum of 40 instances per server(the same number of threads).
To try to achieve this I have created a class called ThreadLocalXMLParser and changed the servlet code.
ThreadLocalXMLParser:


Then I have changed the fragment of code from the servlet to use it:



Well, the problem is that I figured out that even when I get the same thread, for example: Servlet.Engine.Transports : 0 the Parser gets createde again? (the debug line Storing parser... is called allways no matter is the same thread).
This is my first time with ThreadLocal, and the few I�ve read about this should problably work.
Any clues about how to do this?
[ September 22, 2006: Message edited by: Bear Bibeault ]
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you don't get a satisfactory answer for this question after a day or two, let me know and I can move it to our Threads and Synchronization forum for you.
 
Paul Clapham
Sheriff
Posts: 22375
42
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't understand why that code doesn't work, although I have a couple of theories.

However I can't imagine why you need to reuse XML parsers, since an XML parser contains almost nothing that can't be regenerated within microseconds. But maybe there's more to these parsers than that, although if you are willing to share them among users like that then they can't be storing any state information. So I agree that attaching them to the session is not the right thing to do. But what's wrong with just creating a new one whenever a request runs?

If they are really expensive to create, then why not implement an object pool that contains 40 parsers and have the requests check the parsers out of the pool when they need one? I know that doesn't answer the ThreadLocal question but it does advance you towards solving your problem.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the threads are rendered as complete as soon as it compelts is execution.That is why it creats new thread each time for every request and the number of worker threads might be the max number of threads that can exits at any point of time.

Tough the usage of ThreadLocal looks fine to me.
 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ben Souther:
If you don't get a satisfactory answer for this question after a day or two, let me know and I can move it to our Threads and Synchronization forum for you.


Hi Ben,

coul�d you pls do it now. Still stucked on this . Searching the web for an answer.

Tx.


 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I�m also concerned about this:

http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html

Any one with some experience using ThreadLocal around? Is this implementation wrong?

Any help will be appreciated.

regards.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I think Paul asked a very good question: why do you need to store the parsers in the first place? What bad happens when you simply recreate one every time?
 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Well, I think Paul asked a very good question: why do you need to store the parsers in the first place? What bad happens when you simply recreate one every time?


We have really specific performance concerns on this app. So would be better to have them reused.
 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Got an information from an IBM consultant that this is problably hapenning because I�m testing using the internal websphere version that ships with RSA tool from IBM. It should work on a real environment. Still didn�t have the time to test. I�ll let you know when I test.

 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll second the pool suggestion. Seems like a more reliable solution than depending on whether the container reuses threads or makes new ones or comes up with some completely different idea in the next release.
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with theories of having a pool of parsers or to create new one everytime unless you have specifically boiled down performance issue to the creation of new parser object.

As earlier mentioned, I don't think parser should have big overhead of instance variables (if it does have then the pooling should work better).

One other question I had was -- you are not in anyway transforming the xml to something different format, are you? Here are you just referring to the XML Parser, right? Because transformation would be a different thing to deal with, in which case we have to figure out if there are multiple stylesheet (sort of) to apply on single XML data model. In that case somehow we need to figure out how to Cache the stylesheet uniquely so for mulitple requests with different XML it doesn't have to process the same set of stylesheet repeatedly.

It would really helpful to know if you really have boiled down the performance issue to the particular parser creation calls.

Thanks
Maulin
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Marcos Maia:


We have really specific performance concerns on this app. So would be better to have them reused.


Just be sure to *measure* whether this particular change really helps in meeting your performance requirements. If it doesn't, it just unecessarilly complicates the code and thereby makes working on it more costly without any gains.
 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Maulin Vasavada:
I agree with theories of having a pool of parsers or to create new one everytime unless you have specifically boiled down performance issue to the creation of new parser object.

As earlier mentioned, I don't think parser should have big overhead of instance variables (if it does have then the pooling should work better).

One other question I had was -- you are not in anyway transforming the xml to something different format, are you? Here are you just referring to the XML Parser, right? Because transformation would be a different thing to deal with, in which case we have to figure out if there are multiple stylesheet (sort of) to apply on single XML data model. In that case somehow we need to figure out how to Cache the stylesheet uniquely so for mulitple requests with different XML it doesn't have to process the same set of stylesheet repeatedly.

It would really helpful to know if you really have boiled down the performance issue to the particular parser creation calls.

Thanks
Maulin



I don�t need to transform the XML document. It�s used only to passa information from the POS to server over the private network that is used for the application. In fact I�m still stucked with this solution, as it has been recommended by a IBM consultant(a famous one ).
. What happened is that I asked for help from the IBM support and they say it does not work on my local machine bacause the Websphere threads from the server that cames packed with RSA 6 have a short life, and that this should work on a real websphere environment.
This is a problem for me, because I didn�t have the time to test it under a standa alone server yet, and also I got disapointed that I don�t have an environment I could "really" test my applications using the RSA tool? Isn�t this dummy? So ASAP I will return to this problem trying to test it under a standalone server and post the results here.

regards.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!