date:20090511

RE: Performance with many small requests

2009-05-11 Thread Peter Crowther

 From: David kerber [dcker...@verizon.net]
 My cpu usage for tomcat
 has gone from bouncing between 0 and 1 in task manager, to a steady 2
 since more threads are now actually doing work instead of waiting around
 for their turn at the code, my disk writes per sec in perfmon have also
 more than doubled, and the destination log file is growing much faster
 as well.

All excellent news.  The fact that you've seen the performance double means 
that there was, in fact, a bottleneck there.  Have you taken a new thread dump 
to see whether the locks (almost certainly on the log write) are still a 
problem?  If so, you might have to go to a more complex scheme such as multiple 
log files managed by a pool manager.  Don't even try to write the pool manager 
yourself; they're horribly messy things to get right and shake the race 
conditions out*.  I half-remember Jakarta Commons has one that can be adapted 
if you get to that stage.

 Thanks a ton!!!

No problem.

- Peter

* Yes, I did implement one.  I still have the scars.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: AW: Permanent Redirect?

2009-05-11 Thread Alexander Diedler

Hello,
Yes it works with Tuckey.org but, what about http and https?
In my urlrewrite.xml only this entry:
urlrewrite
   rule
   from/(.*)$/from
   to type=redirecthttp://www.thenewserver.de/$1/to
/rule
/urlrewrite

But if the user came from https he should also redirected to
https://thenewserver.de/?someparameters


Greetings
Alexander


-Ursprüngliche Nachricht-
Von: Pid [mailto:p...@pidster.com] 
Gesendet: Donnerstag, 30. April 2009 11:51
An: Tomcat Users List
Betreff: Re: AW: Permanent Redirect?

Alexander Diedler wrote:
 Hmm..
 Seems not to be work for me The target is a
http://www.siteA.de/index.jsp?WERWERWERWERWER redirect to
http://www.siteB.de/index.jsp?WERWERWERWERWER
 I download the package, unzip and put the new content to a new, empty
docBase folder. I edit my ROOT.xml in SiteA point to this new folder and
create an empty web.xml that contains only 
   filter
filter-nameUrlRewriteFilter/filter-name

filter-classorg.tuckey.web.filters.urlrewrite.UrlRewriteFilter/filter-cla
ss
 /filter
 filter-mapping
filter-nameUrlRewriteFilter/filter-name
url-pattern/*/url-pattern
 /filter-mapping
 
 But where I have to define, what is the target of the redirect?

Have you read: http://tuckey.org/urlrewrite/manual/3.0/

p


 My Tomcat:
 [tomcat-base]/conf/Catalina/www.siteA.de/ROOT.xml  (Context docBase point
to D:\Inetpub\SiteA)
 [tomcat-base]/conf/Catalina/www.siteB.de/ROOT.xml  (Context docBase point
to D:\Inetpub\SiteA)
 [tomcat-base]/conf/Catalina/www.siteC.de/ROOT.xml  (Context docBase point
to D:\Inetpub\SiteA)
 
 Same DocBase because it is a CMS with the functionality to show different
content for different domains.
 Server.xml:
 Connector protocol=org.apache.coyote.http11.Http11Protocol
port=443 address=xxx.xxx.xxx.209 addressminSpareThreads=5
maxSpareThreads=75
enableLookups=true disableUploadTimeout=true 
acceptCount=100  maxThreads=200
scheme=https secure=true SSLEnabled=true
keystoreFile=D:/Keystore/siteA.kdb keystorePass=changeit
clientAuth=false sslProtocol=TLS/
 
Connector protocol=org.apache.coyote.http11.Http11Protocol
port=443 address=xxx.xxx.xxx.210 addressminSpareThreads=5
maxSpareThreads=75
enableLookups=true disableUploadTimeout=true 
acceptCount=100  maxThreads=200
scheme=https secure=true SSLEnabled=true
keystoreFile=D:/Keystore/siteB.kdb keystorePass=changeit
clientAuth=false sslProtocol=TLS/
 
Connector protocol=org.apache.coyote.http11.Http11Protocol
port=443 address=xxx.xxx.xxx.211 addressminSpareThreads=5
maxSpareThreads=75
enableLookups=true disableUploadTimeout=true 
acceptCount=100  maxThreads=200
scheme=https secure=true SSLEnabled=true
keystoreFile=D:/Keystore/www_siteC.kdb
keystorePass=changeit
clientAuth=false sslProtocol=TLS/
 
 If this is a very bad configuration, I am open for any better suggestions
of you...
 
 Greetings
 Alexander Diedler
 
 
 -Ursprüngliche Nachricht-
 Von: Pid [mailto:p...@pidster.com] 
 Gesendet: Montag, 27. April 2009 11:11
 An: Tomcat Users List
 Betreff: Re: Permanent Redirect?
 
 Alexander Diedler wrote:
 Hello everybody,

 I have a question to implement a permanent redirect for an old domain to
 a new domain on the Tomcat 6.0.16 Server.

 It is definied in the server.xml as it own connector (for SSL) and now
 we want, that if we fill-in www.websiteA.de http://www.websiteA.de we
 will be redirected to www.websiteB.de http://www.websiteB.de
 automatically.
 
 A small webapp deployed in websiteA.de/ROOT that contains a servlet
 Filter which is coded to issue an appropriate redirect to the new URL.
 
 You could avoid rolling your own and try: tuckey.org/urlrewrite/
 
 p
 
 
 Greetings

 Alexander

  

 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



smime.p7s
Description: S/MIME cryptographic signature

centralized server

2009-05-11 Thread Kaushal Shriyan

Hi,

Is there a way to log all the catalina.out files of tomcat hosted on
different servers to a centralized server and view it using a web Interface?

Thanks and Regards

Kaushal

RE: Tomcat 5.5.27 404 for JSP's in a particular derectory

2009-05-11 Thread Mackstar

Caldarale, Charles R wrote:

1. The shuppin directory is a subdirectory which is inside a ROOT
application directory, it has other sibling directories which are
working correctly.

They may appear to work correctly, but that's probably just an accident.
Each webapp should be directly under the Host appBase (by default,
that's Tomcat's webapps directory). Placing a directory under
webapps/ROOT makes it part of the default webapp rather than being its own
webapp.

Sounds like your directory setup is incorrect, as well might be other
config settings. What Context elements have you specified? Where are
they located? What's in the individual webapp WEB-INF/web.xml files?

OK I spoke too soon, you were right the invoker issue did not sort out my
problem

I have the following in my server.xml

Host name=auction appBase=/var/www/auction
unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
Aliasauction.provide-cars.com/Alias
/Host

I have a dir called /var/www/auction/ROOT in which I have
/var/www/auction/ROOT/shuppin as well as
/var/www/auction/ROOT/dir and /var/www/auction/ROOT/members

the dir and members dirs are working fine, have no problem accessing beans
etc in /var/www/auction/ROOT/WEB-INF/Classes. I have added no other contexts
and am completely lost why this shuppin dir should throw 404's unless you
change its name.

As I said earlier I do have a package/dir at
/var/www/auction/ROOT/WEB-INF/Classes/shuppin/ which may have something to
do with it?

This is wierd because I had it working once?

Thanks again for any help

Richard

--
View this message in context:
http://www.nabble.com/Tomcat-5.5.27-404-for-JSP%27s-in-a-particular-derectory-tp23475510p23481918.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat 5.5.27 404 for JSP's in a particular derectory

2009-05-11 Thread Mackstar


Thanks all for your help

I am stupid stupid stupid

I had my ftp set up so that even though ROOT houses my app I have ROOT and
shuppin in the same directory aswell as shuppin inside the ROOT dir so it
looked in the sibling of ROOT rather than the child of ROOT

Thanks again for your help

Richard

-- 
View this message in context: 
http://www.nabble.com/Tomcat-5.5.27-404-for-JSP%27s-in-a-particular-derectory-tp23475510p23482270.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 5.5.27 404 for JSP's in a particular derectory

2009-05-11 Thread David Smith

Mackstar wrote:
 Thanks all for your help

 I am stupid stupid stupid

 I had my ftp set up so that even though ROOT houses my app I have ROOT and
 shuppin in the same directory aswell as shuppin inside the ROOT dir so it
 looked in the sibling of ROOT rather than the child of ROOT

 Thanks again for your help

 Richard

   
Yup... that will do it.  shuppin as a sibling would have been seen as a
webapp and it would have ended up with the request.

--David


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Trouble parsing datetime strings

2009-05-11 Thread David kerber

This is related to the performance issues discussed in the thread 
Performance with many small requests.


When I reworked my servlet to synchronize only on pieces that needed to 
be synchronized, rather than on the entire request processing routine, I 
am now throwing an exception when parsing a string into a java.util.Date 
variable.  It only happens occasionally, maybe once every few dozen to a 
hundred or so requests, and I can't figure out why it doesn't work all 
the time.


Declared at the class level, I have:

   private static final SimpleDateFormatsdfFullDateTime = new 
SimpleDateFormat( -MM-dd HH:mm:ss );



Then in the request processing method, I have

   dateTimeStr = dateStr +   + timeStr;
   try {
   dataDate = sdfFullDateTime.parse( dateTimeStr );
   } catch ( Exception e ) {
   writeLog( Unable to parse dataTime string: ', dateTimeStr + 
':  + e );

   }


(the try/catch is there only for debugging this issue), and in the log 
I'm seeing:


2009-05-11 09:19:54: Unable to parse dateTime string: ':  '2009-05-11 
09:19:37': java.lang.NumberFormatException: For input string: '



Which I don't understand at all; dateDate (java.util.Date), dateStr 
(String), timeStr (String) and dateTimeStr (String) are all declared in 
the processing method, NOT at the class level.


Maybe I should move the declaration of the SimpleDateFormat into the 
processing method?  Or synchronize the date parse?



I'm kind of lost here; any help appreciated!!

Dave



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble parsing datetime strings

2009-05-11 Thread Xie Xiaodong

Hello,

Date formats are not synchronized. It is recommended to create separate
format instances for each thread. If multiple threads access a format
concurrently, it must be synchronized externally.
This is from the reference of JDK API.


2009/5/11 David kerber dcker...@verizon.net

 This is related to the performance issues discussed in the thread
 Performance with many small requests.

 When I reworked my servlet to synchronize only on pieces that needed to be
 synchronized, rather than on the entire request processing routine, I am now
 throwing an exception when parsing a string into a java.util.Date variable.
  It only happens occasionally, maybe once every few dozen to a hundred or so
 requests, and I can't figure out why it doesn't work all the time.

 Declared at the class level, I have:

   private static final SimpleDateFormatsdfFullDateTime = new
 SimpleDateFormat( -MM-dd HH:mm:ss );


 Then in the request processing method, I have

   dateTimeStr = dateStr +   + timeStr;
   try {
   dataDate = sdfFullDateTime.parse( dateTimeStr );
   } catch ( Exception e ) {
   writeLog( Unable to parse dataTime string: ', dateTimeStr + ':  +
 e );
   }


 (the try/catch is there only for debugging this issue), and in the log I'm
 seeing:

 2009-05-11 09:19:54: Unable to parse dateTime string: ':  '2009-05-11
 09:19:37': java.lang.NumberFormatException: For input string: '


 Which I don't understand at all; dateDate (java.util.Date), dateStr
 (String), timeStr (String) and dateTimeStr (String) are all declared in the
 processing method, NOT at the class level.

 Maybe I should move the declaration of the SimpleDateFormat into the
 processing method?  Or synchronize the date parse?


 I'm kind of lost here; any help appreciated!!

 Dave



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Sincerely yours and Best Regards,
Xie Xiaodong

RE: Trouble parsing datetime strings

2009-05-11 Thread Caldarale, Charles R

 From: David kerber [mailto:dcker...@verizon.net]
 Subject: Trouble parsing datetime strings

 Declared at the class level, I have:

 private static final SimpleDateFormatsdfFullDateTime = new
 SimpleDateFormat( -MM-dd HH:mm:ss );

Oops.  Read the fine print for SimpleDateFormat:

Date formats are not synchronized. It is recommended to create separate format 
instances for each thread. If multiple threads access a format concurrently, it 
must be synchronized externally.

Rather than introducing another bottleneck by synchronizing, you may be better 
off keeping separate SDF objects for each request.  If this is your only 
webapp, you could get away with storing one per thread as a ThreadLocal.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: how to enable management agent on a process

2009-05-11 Thread Caldarale, Charles R

 From: Anamika raj [mailto:rajnam...@gmail.com]
 Subject: Re: how to enable management agent on a process

 i am not getting how to set
 com.sun.management.jmxremote in the system property.

The basic answer is that you set it the same way you set any other Java system 
property.  Perhaps you need to learn Java fundamentals.

It's difficult to give you specifics when you don't bother to provide basic 
information such as Tomcat version, JVM level, and the platform you're running 
on.  Also, if it's Windows, are you running Tomcat via the scripts, or as a 
service?  If Linux/UNIX, how are your starting Tomcat?

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Performance with many small requests

2009-05-11 Thread David kerber


Peter Crowther wrote:

From: David kerber [dcker...@verizon.net]
My cpu usage for tomcat
has gone from bouncing between 0 and 1 in task manager, to a steady 2
since more threads are now actually doing work instead of waiting around
for their turn at the code, my disk writes per sec in perfmon have also
more than doubled, and the destination log file is growing much faster
as well.



All excellent news.  The fact that you've seen the performance double means 
that there was, in fact, a bottleneck there.  Have you taken a new thread dump 
to see whether the locks (almost certainly on the log write) are still a 
problem?  If so, you might have to go to a more complex scheme such as multiple 
log files managed by a pool manager.  Don't even try to write the pool manager 
yourself; they're horribly messy things to get right and shake the race 
conditions out*.  I half-remember Jakarta Commons has one that can be adapted 
if you get to that stage.
  
From what I can tell now, it looks like most of my wait time is on 
socket reads.  In the thread dump I took about 20 minutes ago, I didn't 
see any waiting on disk writes:


The line listed in this one is my inputStream.read():

[2009-05-11 08:20:09] [info] http-1024-Processor8
[2009-05-11 08:20:09] [info] daemon
[2009-05-11 08:20:09] [info] prio=6 tid=0x270e83c8
[2009-05-11 08:20:09] [info] nid=0xcd4
[2009-05-11 08:20:09] [info] runnable
[2009-05-11 08:20:09] [info] [0x2755f000..0x2755f9e4]
[2009-05-11 08:20:09] [info] at 
java.net.SocketInputStream.socketRead0(Native Method)
[2009-05-11 08:20:10] [info] at 
java.net.SocketInputStream.read(Unknown Source)
[2009-05-11 08:20:10] [info] at 
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:747)
[2009-05-11 08:20:10] [info] at 
org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:777)
[2009-05-11 08:20:10] [info] at 
org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:115)
[2009-05-11 08:20:10] [info] at 
org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:712)
[2009-05-11 08:20:10] [info] at 
org.apache.coyote.Request.doRead(Request.java:423)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:283)
[2009-05-11 08:20:10] [info] at 
org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:404)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:298)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:192)
[2009-05-11 08:20:10] [info] at 
eddsrv.EddRcvr.processRequest(EddRcvr.java:199)

[2009-05-11 08:20:10] [info] at eddsrv.EddRcvr.doPost(EddRcvr.java:94)
[2009-05-11 08:20:10] [info] at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
[2009-05-11 08:20:10] [info] at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
[2009-05-11 08:20:10] [info] at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
[2009-05-11 08:20:11] [info] at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
[2009-05-11 08:20:11] [info] at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
[2009-05-11 08:20:11] [info] at 
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
[2009-05-11 08:20:11] [info] at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
[2009-05-11 08:20:11] [info] at 
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
[2009-05-11 08:20:11] [info] at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

[2009-05-11 08:20:11] [info] at java.lang.Thread.run(Unknown Source)
[2009-05-11 08:20:11] [info]


This one seems to be waiting on something in tomcat itself:

[2009-05-11 08:19:49] [info] http-1024-Processor45
[2009-05-11 08:19:49] [info] daemon
[2009-05-11 08:19:49] [info] prio=6 tid=0x26fa6f38
[2009-05-11 08:19:49] [info] nid=0x340
[2009-05-11

Re: Trouble parsing datetime strings

2009-05-11 Thread Konstantin Kolinko

2009/5/11 David kerber dcker...@verizon.net:
 This is related to the performance issues discussed in the thread
 Performance with many small requests.

 When I reworked my servlet to synchronize only on pieces that needed to be
 synchronized, rather than on the entire request processing routine, I am now
 throwing an exception when parsing a string into a java.util.Date variable.
  It only happens occasionally, maybe once every few dozen to a hundred or so
 requests, and I can't figure out why it doesn't work all the time.

 Declared at the class level, I have:

   private static final SimpleDateFormat    sdfFullDateTime = new
 SimpleDateFormat( -MM-dd HH:mm:ss );


 Then in the request processing method, I have

   dateTimeStr = dateStr +   + timeStr;
   try {
       dataDate = sdfFullDateTime.parse( dateTimeStr );
   } catch ( Exception e ) {
       writeLog( Unable to parse dataTime string: ', dateTimeStr + ':  +
 e );
   }


 (the try/catch is there only for debugging this issue), and in the log I'm
 seeing:

 2009-05-11 09:19:54: Unable to parse dateTime string: ':  '2009-05-11
 09:19:37': java.lang.NumberFormatException: For input string: '


 Which I don't understand at all; dateDate (java.util.Date), dateStr
 (String), timeStr (String) and dateTimeStr (String) are all declared in the
 processing method, NOT at the class level.

 Maybe I should move the declaration of the SimpleDateFormat into the
 processing method?  Or synchronize the date parse?


 I'm kind of lost here; any help appreciated!!

 Dave


As the JavaDoc says
http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html

Date formats are not synchronized. It is recommended to create
separate format instances for each thread

You may either create a new instance of SimpleDateFormat each time, or
add a synchronization around that part of code, or use a ThreadLocal
(though ThreadLocal has its own caveats as the threads belong to
Tomcat and are shared among applications).

Without profiling you would not know which one of the ways I am
mentioning is faster.

Maybe I would start with creating a new instance each time, as GC for
short-living objects seems to be cheap in recent JREs. Though without
profiling you will not get the numbers.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Performance with many small requests

2009-05-11 Thread Caldarale, Charles R

 From: David kerber [mailto:dcker...@verizon.net]
 Subject: Re: Performance with many small requests

  From what I can tell now, it looks like most of my wait time is on
 socket reads.  In the thread dump I took about 20 minutes ago, I didn't
 see any waiting on disk writes:

 The line listed in this one is my inputStream.read():

Waiting for the body of the request to show up.

 This one seems to be waiting on something in tomcat itself:

Waiting for the request header to show up.

If that's all you're seeing in the thread dump, then it does look like the 
network is sluggish, as I think you mentioned before.  You might try running 
Wireshark or equivalent to monitor the traffic and see just how long it takes 
for each segment of the message to be delivered to the server.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Trouble parsing datetime strings

2009-05-11 Thread David kerber


Konstantin Kolinko wrote:

...

As the JavaDoc says
http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html

Date formats are not synchronized. It is recommended to create
separate format instances for each thread

You may either create a new instance of SimpleDateFormat each time, or
add a synchronization around that part of code, or use a ThreadLocal
(though ThreadLocal has its own caveats as the threads belong to
Tomcat and are shared among applications).

Without profiling you would not know which one of the ways I am
mentioning is faster.

Maybe I would start with creating a new instance each time, as GC for
short-living objects seems to be cheap in recent JREs. Though without
profiling you will not get the numbers.
  


Thanks, guys!  Obviously I missed that part when I was looking for a fix 
for this issue.  For now, I took the simplest (from a coding standpoint) 
way out, and moved the declaration of the SimpleDateFormat into each 
method where it's used, and that has fixed the issue.  From the quick 
reading I did, I imagine that will give me a bit of a performance hit 
compared to using ThreadLocal, but since I've never used the ThreadLocal 
pattern before, I didn't want to try implementing it on the fly, just to 
fix this issue.  As for whether synchronization would be faster than 
local declaration, I'll try doing some benchmarking at some point.


Dave



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: how to enable management agent on a process

2009-05-11 Thread André Warnier

Well, you did not mention the platform under which you are running 
Tomcat, nor the Tomcat version, not the Java version, so I could only 
give you general stuff.
(And if this happened to be a Tomcat running under Windows, please also 
indicate how you are starting Tomcat).


Anamika raj wrote:

The link which you gave me i have gone through it before ...but i am not
getting how to set 

com.sun.management.jmxremote in the system property. 
  
as it is written in the given link-


To enable the JMX agent for local access, set this system property when you
start the JVM or Java application:

com.sun.management.jmxremote 


I am not getting how to do it.
please help me
thanx




awarnier wrote:

Anamika raj wrote:

i am configuring a server to monitor it with jconsole locally.when i m
starting the jconsole PID is showing for that server in the jconsole(for
local monitoring) but it is giving me message that management agent is
not
enables on that process.

how to enable the management agent for that process or tell me for any
process in simple,step by step.

i didnt do any configuration to monitor that server with Jconsole,do i
need
to do anything to configure any server with jconsole?
I want to know if i want to monitor any server what configuration I have
to
do. 


Read :
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html

Example jvm settings for starting Tomcat to allow jconsole monitoring (! 
with no security !) :


-Dcom.sun.management.jmxremote.port=8200 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org








-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Getting the Right High Availability Architecture for Tomcat

2009-05-11 Thread Nenad Kovacevic

Caldarale, Charles R wrote:

Have you considered doing the SSL processing in the load balancer(s)? It
would make life simpler.

- Chuck

From application's perspective it really does not make much of a difference
where SSL is done - actually it does make now after your explanation -
thanks for that - however this change would need to be run and approved by
our networking and security people first. In any case I am afraid that even
if they are willing to move SSL processing to the balancers this change may
not happen in time for our first application, so we might end up with the
setup as I described it in my original post.

Our applications do not issue concurrent requests to the servers, i.e. they
are classical web applications where the user activates a control on a page
and then waits for a page to refresh or a new page to load. Therefore under
normal usage scenarios concurrent requests should really not happen. I say
normal as it is possible for a user to resubmit a request by reloading a
page using browser controls. However we warn the users to use only controls
on the page and gray-out submit buttons once a request is submitted so
hopefully this should not be an issue.

With such an application in mind would you see an issue with not
implementing sticky session? Again, I was able to test that and the only
issue that I am seeing is that JSESSIONID changes depending on what Tomcat
instance processed it, but again, I am not sure if that is really an issue
or not?

Thanks
Nash

--
View this message in context:
http://www.nabble.com/Getting-the-Right-High-Availability-Architecture-for-Tomcat-tp23452018p23485311.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Getting the Right High Availability Architecture for Tomcat

2009-05-11 Thread André Warnier


Nenad Kovacevic wrote:


Caldarale, Charles R wrote:


Have you considered doing the SSL processing in the load balancer(s)?  It
would make life simpler.

 - Chuck





From application's perspective it really does not make much of a difference

where SSL is done - actually it does make now after your explanation -
thanks for that - however this change would need to be run and approved by
our networking and security people first. In any case I am afraid that even
if they are willing to move SSL processing to the balancers this change may
not happen in time for our first application, so we might end up with the
setup as I described it in my original post. 


Our applications do not issue concurrent requests to the servers, i.e. they
are classical web applications where the user activates a control on a page
and then waits for a page to refresh or a new page to load. Therefore under
normal usage scenarios concurrent requests should really not happen. I say
normal as it is possible for a user to resubmit a request by reloading a
page using browser controls. However we warn the users to use only controls
on the page and gray-out submit buttons once a request is submitted so
hopefully this should not be an issue.

With such an application in mind would you see an issue with not
implementing sticky session? Again, I was able to test that and the only
issue that I am seeing is that JSESSIONID changes depending on what Tomcat
instance processed it, but again, I am not sure if that is really an issue
or not?


Not sure if it is relevant here :
a browser will make (quasi-)concurrent requests to the server, for 
example when you load a html frames document.  The first request will 
be for the frames document itself, but as soon as that one is returned, 
each frame in it will be the object of a new request.
A similar case happens when a document merely contains img or style 
or script tags.  To fill these slots, the browser will issue several 
requests (and probably establish several connections) in parallel.
I know that this kind of thing can play havoc with some authentication 
schemes for instance.  Again, I don't know if it is really a cause for 
concern in this situation.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Getting the Right High Availability Architecture for Tomcat

2009-05-11 Thread Nenad Kovacevic

Nenad Kovacevic wrote:

Caldarale, Charles R wrote:

Have you considered doing the SSL processing in the load balancer(s)? It
would make life simpler.

- Chuck

From application's perspective it really does not make much of a
difference where SSL is done - actually it does make now after your
explanation - thanks for that - however this change would need to be run
and approved by our networking and security people first. In any case I am
afraid that even if they are willing to move SSL processing to the
balancers this change may not happen in time for our first application, so
we might end up with the setup as I described it in my original post.

Our applications do not issue concurrent requests to the servers, i.e.
they are classical web applications where the user activates a control on
a page and then waits for a page to refresh or a new page to load.
Therefore under normal usage scenarios concurrent requests should really
not happen. I say normal as it is possible for a user to resubmit a
request by reloading a page using browser controls. However we warn the
users to use only controls on the page and gray-out submit buttons once a
request is submitted so hopefully this should not be an issue.

Thanks
Nash

Sorry, forgot to mention we are running Tomcat 6.0.18 on SunOS 5.8, our
current java is 1.5 update 11.

--
View this message in context:
http://www.nabble.com/Getting-the-Right-High-Availability-Architecture-for-Tomcat-tp23452018p23485700.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Getting the Right High Availability Architecture for Tomcat

2009-05-11 Thread Caldarale, Charles R

 From: Nenad Kovacevic [mailto:micami...@yahoo.com]
 Subject: RE: Getting the Right High Availability Architecture for
 Tomcat

 Our applications do not issue concurrent requests to the servers, i.e.
 they are classical web applications where the user activates a control
 on a page and then waits for a page to refresh or a new page to load.

Unless the pages are incredibly simplistic, there will be multiple concurrent 
requests.  Each embedded object in the page along with any .css files will 
cause the browser to issue multiple requests in parallel.  You also have no 
control over the user getting impatient and clicking more links or buttons 
before the prior one responds.

 However we warn the users to use only controls on the page and gray-out
 submit buttons once a request is submitted so hopefully this should not
 be an issue.

Sorry, but that's rather naive.  You cannot base the integrity of your 
application on trusting the user to always do the right thing.

 With such an application in mind would you see an issue with not
 implementing sticky session?

Yes, I would.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

65 matches

Mail list logo