Re: Compilation problem when i release tomcat 5.5.26 to tomcat 5.5.27

2009-01-07 Thread Mark Hagger
I had a similar problem when I switched to tomcat6, as a workaround I
ended up modifying my jsp to build the string outside of the %=..% bit
and insert it in one lump.

Ie changed something like


%= ' + otherthing + '%

into

%
String txt = ' + otherthing + ';
%
%= txt %

which seemed to make it work again.  I couldn't really decide if this
was a tomcat bug or not and promptly forgot all about it really.

Mark


On Wed, 2009-01-07 at 17:40 +0100, Philippe Couas wrote:
 Hi,
  
 I have replace tomcat 5.5.26 to tomcat 5.5.27 on same server with same JDK
 and same config.
 
 
 I have folowing error message
 jasper.JasperException: /jsp/servlet24/supervisionv5.jsp(6,23) Attribute
 value request.getContextPath()+/jsp/servlet24/supervisionv4.jsp is quoted
 with  which must be escaped when used within the value
 Code :
 
 
 inf:redirect
 page=%=request.getContextPath()+/jsp/servlet24/supervisionv4.jsp%
 inf:param name=id value=%=request.getParameter(id) % /
 inf:param name=repobj value=%=request.getParameter(repobj) % /
 inf:param name=design value=true /
 inf:param name=sitepreffix value=%=request.getParameter(sitepreffix)
 % /
 inf:param name=ipl value=%=request.getParameter(ipl) % /
 inf:param name=context value=%=request.getParameter(context) % /
 inf:param name=niveau value=%=request.getParameter(niveau) % /
 inf:param name=sectionspreffix
 value=%=request.getParameter(sectionspreffix) % /
 /inf:redirect
 
 Problem is in line
 inf:redirect
 page=%=request.getContextPath()+/jsp/servlet24/supervisionv4.jsp%
 Why could i not make this now ?
  
 Regards
 Philippe
 
  
 
 
 
 This email has been scanned for all known viruses by the MessageLabs SkyScan 
 service.



This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

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



RE: Redeploy leaks

2009-01-06 Thread Mark Hagger
On Sat, 2009-01-03 at 14:30 -0500, Cosio, Raul wrote:
 Memory leak is an advanced task. But once understood is very easy to fix
 them, just follow some simple rules, most common situations are: 1) Not

Usually a matter of torturing yourself for some time following
classloader trees, together with various static instantiations.  Logging
systems and Axis/jakarta-commons stuff have been the main causes of
problems for me.

This article was useful for me:

http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

I suppose that they are very easy to fix once you work out precisely
what is causing a leak, but that's a bit like saying that most bugs are
very easy to fix - but thats a bit misleading isn't it, since you could
spend hours/days tracking down the bug in the first place.

Although its obviously nice to track down all the leaks in your app so
that you could sit redeploying all day to your hearts content (I'll
probably be burned at the stake for this next bit) but I do sometimes
suspect that its not worth the effort and just live with having to
restart your tomcat instance from time to time depending on your
redeploy strategies.

Mark




This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

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



Re: Migrating to tomcat 6 gives formatted currency amounts problem

2008-09-11 Thread Mark Hagger
You are almost certainly having a problem with (default) character
encodings on your system, usual things to check are the encoding that
the JVM is using, for example what does:

echo $LANG

return (usually controlled by what's defined in /etc/sysconfig/i18n -
although I'm not familiar with Ubuntu systems).

The most likely thing is that the tomcat servlet is effectively
generating content in UTF-8, and then trying to return this character to
the end client, via a PrintWriter, in ISO1 where the currency symbol in
use is not supported by ISO1, hence the '?'.  Alternatively tomcat is
returning either ISO1 or UTF-8 characters but not declaring them as such
in its response headers, leaving the browser confused and its choosing
the wrong default.  Be useful to know what headers tomcat is returning
really.

I can't begin to count the number of times I've had problems with
character encoding issues in the past, both on response and request
handling, fortunately the general trend for everything (including mobile
browsers) to support UTF-8 is slowly making life much much easier.

Mark




This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



mod_jk socket_timeout vs reply_timeout

2006-12-13 Thread Mark Hagger
Hi,

I'm just considering an update to our workers.properties for the mod_jk
Apache plugin.

I'm not entirely sure what the difference between the socket_timeout and
reply_timeout handling is, if any.

socket_timeout is described as:

Socket timeout in seconds used for communication channel between JK and
remote host. If remote host does not respond inside that timeout the JK
will generate an error, and retry again. If set to value zero (default)
the JK will wait for infinite on all socket operations.

whereas reply_timeout is:

Reply_timeout property told webserver to wait some time for reply to a
forwarded request before considering the remote tomcat is dead and
eventually switch to another tomcat in a cluster group.

These sound very similar concepts to me, should you set both to the same
time?  Or only ever set one of them?  Or am I missing a crucial
distinction here?

Mark




This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk socket_timeout vs reply_timeout

2006-12-13 Thread Mark Hagger
To be honest I got a bit confused by that reply so I delved into the
source code (although my C is somewhat rusty).

So as I see it the socket_timeout is the read/write timeout for the
underlying TCP socket (ie at OS level, and set by setsockopt() or
whatever), and any given socket could be used for multiple in-flight
communications between Apache and Tomcat.

Whereas the reply_timeout is an internal timeout for a specific request,
ie the socket could be functioning fine but a specific reply is too late
to be useful.

So socket_timeout is helpful against servers that have totally failed,
or networks that have fallen apart, but reply_timeout is good for
defending against a box that is perhaps so loaded that replies are
coming too slowly to be useful.

So in general I would speculate that setting both is a good plan, but
socket_timeout ought to be longer than reply_timeout, perhaps by quite a
significant factor.  Settings the other way around would make no sense
at all I imagine, perhaps the mod_jk docs ought to be updated to include
a suitable comment to that effect?

Mark


On Wed, 2006-12-13 at 10:01 -0500, Martin Gainty wrote:
 Hi Mark
 the delta is socket_timeout is a universal timeout for the connection more 
 specifically
 Socket timeout in seconds used for communication channel between JK and 
 remote host. If remote host does not respond inside that timeout the JK will 
 generate an error, and retry again. If set to value zero (default) the JK 
 will wait for infinite on all socket operations.
 What to do if the tomcat connection_timeout is set lower than the socket 
 timeout from AJP?
 
 on the other hand
 reply-timeout gets replies from tomcat via ajp13/ajp14 
 there are 3 conditions which would cause the reply from tomcat to abort
 (recovery_options are set in workers.properties)
 1)tomcat is down or experienced network problems
 marked unrecoverable if recovery_options has 
 RECOVER_ABORT_IF_TCGETREQUEST (recovery_options=1) or
 RECOVER_ABORT_IF_TCSENDHEADER (recovery_options=2)
 set
 
 2)tomcat is down or refuses connection
 marked unrecoverable if recovery_options has RECOVER_ABORT_IF_TCGETREQUEST 
 (recovery_options=1) set
 
 3)tomcat is down or experienced network problem in which case a partial 
 response has been sent back to client
 marked unrecoverable if RECOVER_ABORT_IF_TCSENDHEADER (recovery_options=2) is 
 set
 
 --- 
 This e-mail message (including attachments, if any) is intended for the use 
 of the individual or entity to which it is addressed and may contain 
 information that is privileged, proprietary , confidential and exempt from 
 disclosure. If you are not the intended recipient, you are notified that any 
 dissemination, distribution or copying of this communication is strictly 
 prohibited.
 --- 
 Le présent message électronique (y compris les pièces qui y sont annexées, le 
 cas échéant) s'adresse au destinataire indiqué et peut contenir des 
 renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le 
 destinataire de ce document, nous vous signalons qu'il est strictement 
 interdit de le diffuser, de le distribuer ou de le reproduire.
 - Original Message - 
 From: Mark Hagger [EMAIL PROTECTED]
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, December 13, 2006 7:08 AM
 Subject: mod_jk socket_timeout vs reply_timeout
 
 
  Hi,
  
  I'm just considering an update to our workers.properties for the mod_jk
  Apache plugin.
  
  I'm not entirely sure what the difference between the socket_timeout and
  reply_timeout handling is, if any.
  
  socket_timeout is described as:
  
  Socket timeout in seconds used for communication channel between JK and
  remote host. If remote host does not respond inside that timeout the JK
  will generate an error, and retry again. If set to value zero (default)
  the JK will wait for infinite on all socket operations.
  
  whereas reply_timeout is:
  
  Reply_timeout property told webserver to wait some time for reply to a
  forwarded request before considering the remote tomcat is dead and
  eventually switch to another tomcat in a cluster group.
  
  These sound very similar concepts to me, should you set both to the same
  time?  Or only ever set one of them?  Or am I missing a crucial
  distinction here?
  
  Mark
  
  
  
  
  This email has been scanned for all known viruses by the MessageLabs 
  SkyScan service.
  
  -
  To start a new topic, e-mail: users@tomcat.apache.org
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
 
 
 
 This email has been scanned for all known viruses by the MessageLabs

Re: session replication/tomcat 5.5

2006-11-14 Thread Mark Hagger
Hi,

Sorry to go slightly off the topic, but I have to express surprise (laugh) at 
the 99.99% availability bit.  Its highly laudable to aim at that, indeed 
mobile phone operators claim to aim for, or even require, five 9's, ie 
99.999%, which equates to a massive 315 minutes downtime per year (and 
between you and me I _know_ that mobile operators never even get close).  
99.99% gives you a whole 3153 mins per year, or 52 hours, or 1 hour per week 
of operation per yearAnd thats not much to play with.

As all of us who have tried it know that trying to make a system highly 
redundant so that there are no single points of failure necessarily makes the 
whole thing more complicated and thus if something does go wrong (2 switches 
die at once or something, followed by a disk array failure, and causing an 
unexpected knock on effect etc etc), you can suddenly find that your 
massively complex system has all fallen apart and takes a few hours to put 
back together

Speaking from experience of the tomcat session replication issue, we use it 
and it works well, although in fact we have just 2 tomcat instances at this 
time.  However, problems can occur if a server dies whilst there are a lot of 
active sessions, after recovery of the failed box trying to bring the server 
back into the group and thus attempting to copy all those active sessions 
back can impose surprisingly and dangerous load levels on the live server.  
On a few occasions this did actually grind the live server to a halt and we 
had to restart the entire system from cold, dumping all the live sessions.  
I'm still searching for the optimal configuration for this.

Still, I wish you well in the 99.99% availability quest.

Mark

On Tuesday 14 November 2006 12:09, Mirou, Antoine wrote:
 Hello,

 Could you please give an example of really big sites ?

 How do you organize your cluster (how many members/domains, ...) ?

 Do you use Farm-deployer ?

 Do you use session replication ?

 How do you manage/monitor the cluster ?

 Many questions, sorry, but I'm currently studying the possibility of
 setting up a cluster of tomcat 5.5 for a 99.99% available app with lots of
 user connexions, and I really don't feel confident of my ease with tomcat
 clustering...

 Thanks for your answers.

 Regards,
 Antoine

 -Message d'origine-
 De : Peter Rossbach [mailto:[EMAIL PROTECTED]
 Envoyé : mardi 14 novembre 2006 09:31
 À : Tomcat Users List
 Objet : Re: session replication/tomcat 5.5

 Am 13.11.2006 um 20:27 schrieb David O'Dell:
  Is anyone using session replication in production?

 Yes, at really big sites :-)

  Is there an alternative to using multicasting?

 No, but you can implement you own membership service.

  In the doc http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
 
  It states This is an algorithm that is only efficient when the
  clusters are small.
  I have 6 tomcat instances behind a load balancer, is this still
  considered small?

 Yes, but split your cluster into different domains. Use Apache/mod_jk

  = 1.2.19 with the

 domain attribute. The mod_jk loadbalancer can then route to the right
 backup.

 regards
 Peter

  -
  To start a new topic, e-mail: users@tomcat.apache.org
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 Ce message et toutes les pièces jointes (ci-après le « message ») sont
 confidentiels et établis à l'intention exclusive de ses destinataires.
 Toute utilisation de ce message non conforme à sa destination, toute
 diffusion ou toute publication, totale ou partielle, est interdite, sauf
 autorisation expresse. Si vous recevez ce message par erreur, merci de le
 détruire sans en conserver de copie et d'en avertir immédiatement
 l'expéditeur. Internet ne permettant pas de garantir l'intégrité de ce
 message, la Caisse des Dépôts et Consignations décline toute responsabilité
 au titre de ce message s'il a été modifié, altéré, déformé ou falsifié.

 This email message and any attachments (the email) are confidential and
 intended only for the recipient(s) indicated. If you are not an intented
 recipient, please be advised that any use, dissemination, forwarding or
 copying of this email whatsoever is prohibited without Caisse des Depots et
 Consignations's prior written consent. If you have received this email in
 error, please delete it without saving a copy and notify the sender
 immediately. Internet emails are not necessarily secured, and Caisse des
 Depots et Consignations declines responsibility for any changes that may
 have been made to this email after it was sent.


 -
 To start a new 

Re: session replication/tomcat 5.5

2006-11-14 Thread Mark Hagger
On Tuesday 14 November 2006 16:49, Caldarale, Charles R wrote:
 Your premise is well taken, but the math is a bit shaky.  99.99% uptime
 per week equates to 1 minute of downtime in that period, not one hour,
 which emphasizes you point even more.

Ooops, how embarrassing, I calculated everything in seconds and then 
mysteriously wrote minutes all over the email.  Probably didn't drink enough 
coffee today.

Mark


This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Cluster serialization issue

2006-08-24 Thread Mark Hagger
My best guess is that you've somehow stored the request object itself on
the session, and thus the replication is trying to replicate that to the
other nodes.  

If this is the case then this is almost certainly a bad idea.

Mark


On Thu, 2006-08-24 at 09:04 -0500, Bischoff, Mathew wrote:
 Hi,
   I'm starting to get clustering running on Tomcat I think I've solved
 most of my webapp's non-serialized object issues, but now I'm getting
 the error below. From what I can see , the error is not originating from
 my code in the webapp, and searching the web for this error message
 hasn't turned up anything useful.  Any help would be appreciated ...
 
 Tomcat 5.5.12 on Solaris
 
 2006-08-23 15:22:48,096 DEBUG  DeltaManager -
 Manager [/edjls]: Received SessionMessage of type=(SESSION-DELTA) from
 [org.apache.catalina.cluster.mcast.McastMember[...]]
 2006-08-23 15:22:48,097 DEBUG  DeltaManager -
 Manager [/edjls]: received session [4F2C1D4583B74B19E35243B76B2A35AF.a1]
 delta.
 2006-08-23 15:22:57,837 ERROR  DeltaManager - Unable
 to serialize delta request for sessionid
 [4F2C1D4583B74B19E35243B76B2A35AF.a1]
 java.io.NotSerializableException:
 org.apache.catalina.connector.RequestFacade
 at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
 at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13
 69)
 at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
 at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1
 284)
 at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
 at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13
 69)
 at
 java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
 at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1
 284)
 at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
 at
 java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
 at
 org.apache.catalina.cluster.session.DeltaRequest$AttributeInfo.writeExte
 rnal(DeltaRequest.java:346)
 at
 org.apache.catalina.cluster.session.DeltaRequest.writeExternal(DeltaRequ
 est.java:263)
 at
 org.apache.catalina.cluster.session.DeltaManager.unloadDeltaRequest(Delt
 aManager.java:695)
 at
 org.apache.catalina.cluster.session.DeltaManager.requestCompleted(DeltaM
 anager.java:1249)
 at
 org.apache.catalina.cluster.tcp.ReplicationValve.sendSessionReplicationM
 essage(ReplicationValve.java:328)
 at
 org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve
 .java:271)
 at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
 :105)
 at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
 java:107)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
 48)
 at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:86
 8)
 at
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
 essConnection(Http11BaseProtocol.java:663)
 at
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
 .java:527)
 at
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
 erWorkerThread.java:80)
 at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
 .java:684)
 at java.lang.Thread.run(Thread.java:595)
 
 Matt Bischoff
 Software Developer - FDS External Systems
 Merrill Corporation
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 This email has been scanned for all known viruses by the MessageLabs SkyScan 
 service.



This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tuning garbage collection

2006-07-05 Thread Mark Hagger
Frankly I'd suggest moving to the latest JDK 5.0 release, 1.4.0 is a
pretty old and creaking version of the JVM really.  GC has undergone
huge changes in Sun's JVM from 1.4.0 to their current 1.5.0_06 release.

I also do wonder why you upgraded from tomcat 3 to tomcat 4.  Whats
wrong with tomcat 5?

Mark


On Wed, 2006-07-05 at 07:58 -0500, Ken Gibson wrote:
 Good morning.
 
 I'm hoping someone has experience configuring Tomcat 4 and GC.  We
 recently upgraded our version of Tomcat from 3 to 4, and are now
 experiencing periodic outages. Our problem comes when a Full GC runs.
 What we've seen that a Full GC is run more and more frequently to the
 point of running every few seconds.
 
 My site serves ~3000 JSPs per minute during peak on Solaris 8 using Java
 1.4.0_04-b04 and Tomcat 4.1.31. The server.xml startup commands are
 
 -server -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xms200m
 -Xmx400m
 
 We tried -Xincgc which worked fine for awhile yesterday until all of a
 sudden all free memory on the box was used up presumably while GC ran.
 Research indicates that using -XX:+UseParallelGC might be an option
 except that it isn't supported in 1.4.0. Is upgrading Java to 1.4.2 our
 best solution?
 
 Any suggestions would be greatly appreciated.
 
 Thanks
 
 
 Ken
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 This email has been scanned for all known viruses by the MessageLabs SkyScan 
 service.



This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



painful slow start up with replication

2006-06-26 Thread Mark Hagger
Hi,

I'm running a tomcat cluster with in-memory replication, two nodes in
fact, with around 15 webapps all of which are being replicated, and I'm
slightly surprised by the behaviour of the system when I start both
nodes simultaneously up from cold.

Basically as each node starts up it deploys the webapps sat in its
webapps directory and apparently tries to find another node to pull the
current sessions from, but since both nodes are starting at the same
time there are no nodes to pull from and so both nodes appear to sit
around waiting for some timeout level of time (I assume for the
stateTransferTimeout, which I've left as default 60 seconds).

The net result of this is that the system can take 15 minutes to start
up from coldthis is very very painful!

Obviously I don't want to reduce the stateTransferTimeout because I want
a starting node to be able to sync sessions if a single node is
re-started.

Is there some secret configuration way to do something more sensible, or
am I forced to only start one node at a time (which will be slightly
tricky to achieve in truth).

Mark




This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat as a standalone webserver. Why not?

2006-06-01 Thread Mark Hagger
This issue is discussed endlessly as far as I can see, both camps argue
very well for their case

However, my take from personal experience is that its very handy to
have Apache in front, because it gives you a lot of scope to do little
fixes and tweaks to odd users causing problems without any service
downtime.  For example you can pretty much add Apache Rewrite rules all
over the shop to fix up little issues without having to actually restart
any servers, (just an Apache SIGHUP, or reload).

You can also fiddle with the various request headers, response headers,
logging of request, response headers, with no impact on the back-end
tomcat layer and its webapps.

Of course there is the load balancer issue as well, if you
require/desire to have sticky sessions.

Obviously if your code is perfect and bug free and users are all
perfect, and sticky sessions are not required then then perhaps
tomcat-only is the solution.  Although I've yet to meet an author of bug
free code.

Thats my opinion anyway.

Mark


On Thu, 2006-06-01 at 12:05 +0200, Danny Lee wrote:
 Hi guys!
 
 I wondering if it's really so good to use Tomcat behind a real web 
 server like Apache or IIS.
 
 In my Tomcat 5 book there are two reasons to do it so:
 
 1. Tomcat is not as secure as common web servers, especially if   you 
 want  to use CGI and SSI (I don't think I want to)
 
 2. Tomcat is slow delivering static content.
 
 Well, as long it's just planned to use only 1 server for my application,
 I don't think the both points are true for me. On the Tomcat site 
 there's a note about performance:
 
 When using a single server, the performance when using a native 
 webserver in front of the Tomcat instance is most of the time 
 significantly worse than a standalone Tomcat with its default HTTP 
 connector, even if a large part of the web application is made of static 
 files
 
 And security... what about security? Why is Tomcat behind of Apache
 more secure then without it, especially (as I said) if both are running
 on the same server.
 
 Thanks in advance!
 
 Cheers,
 
 Danny
 
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 This email has been scanned for all known viruses by the MessageLabs SkyScan 
 service.



This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat as a standalone webserver. Why not?

2006-06-01 Thread Mark Hagger
As it happens I can't really begin to count the number of times we've
applied hacks at the Apache level to work around code bugs (did I say
bug?  I meant feature...).  Although to be fair most of these are caused
by users/customers doing odd things outside the spec of the current
code.

We also deal heavily with accesses from mobile phones, each one of which
has new and interesting features in its web browser, some of which just
can't be easily dealt with without direct control over the
request/response headers which Apache makes easy.

But more generally another big win we have found is the ability to
fairly easily have Apache catch certain requests (ie for specific users)
and hand them off to development/staging systems rather than the
production systems.  This is used quite often in our test/release cycle,
and avoids having to have the production system tomcat layer even know
that such hacky stuff is going on, whilst outside users can't
necessarily know which back-end system they are using.

Mark


On Thu, 2006-06-01 at 16:30 +0200, Danny Lee wrote:
 Hi!
 
 Thanks for your answer. I use url-rewrite magic servlet (analog to
 apache mod_rewrite), so I have the same on the fly rewrite 
 functionality (the rewrite-rules.xml is checked every minute or somth).
 
 I do all the request/response stuff in Tomcat as long it's relevant
 and a part of the system I don't want to move a part of functionality
 to Apache, I prefer having all-in-one solution (this is why I use
 Quartz for scheduled tasks and not some chron-jobs).
 
 And I can't see the connection, why my code have to be perfectly bug 
 free? I mean, if I do have bugs Apache wont come and save my ass right? :))




This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Problem: An unexpected error has been detected by HotSpot Virtual Machine

2006-05-08 Thread Mark Hagger
No question that this is a Java VM problem, no java code should be able
to crash a VM, thats the point of java really.

Although back in the real world this is clearly a problem being
tickled by some code in tomcat.  You might want to check that your OS
is fully up to date, and possibly try using different GC/memory settings
which can sometimes avoid hitting these sort of problems.

Failing that, report it to Sun...

Mark


On Mon, 2006-05-08 at 10:45 +0200, Martijn Moret wrote:
 Hi,
 
 We use tomcat 5.5.15 on Solaris 9 (latest recommended patches and j2se
 cluster). once in a  while tomcat crashes, the following message appears:
 #
 # An unexpected error has been detected by HotSpot Virtual Machine:
 #
 #  SIGSEGV (0xb) at pc=0xfee32868, pid=7483, tid=10
 #
 # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
 # Problematic frame:
 # V  [libjvm.so+0x632868]
 #
 # An error report file with more information is saved as hs_err_pid7483.log
 
 Any ideas? is this java, tomcat or lucene?
 
 Regards
 Martijn
 
 hs_err_pid7483.log:
 #
 # An unexpected error has been detected by HotSpot Virtual Machine:
 #
 #  SIGSEGV (0xb) at pc=0xfee32868, pid=7483, tid=10
 #
 # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
 # Problematic frame:
 # V  [libjvm.so+0x632868]
 #
 
 ---  T H R E A D  ---
 
 Current thread (0x001495b8):  JavaThread CompilerThread1 daemon
 [_thread_in_native, id=10]
 
 siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x
 
 Registers:
  O0=0x O1=0x019195dc O2=0x019195bc O3=0xfe9130bc
  O4=0x0191ac9c O5=0x0003 O6=0xb487e6a0 O7=0xfee3283c
  G1=0x00114354 G2=0xfeffe43c G3=0x001143b8 G4=0x0001
  G5=0xfec07fc8 G6=0x G7=0xff351200 Y=0x
  PC=0xfee32868 nPC=0xfee3286c
 
 
 Top of Stack: (sp=0xb487e6a0)
 0xb487e6a0:   0011432c 0191ac74 fefbe000 b487e700
 0xb487e6b0:   0001  0191acb8 
 0xb487e6c0:   feffea58 b487ec5c  0191acb8
 0xb487e6d0:   b487ec5c 00114390 b487e710 fe8f887c
 0xb487e6e0:   b487e708 b487e70c b487e704 0004
 0xb487e6f0:   008ce780 0004 0002 b487ec5c
 0xb487e700:    0002 008ce7a0 
 0xb487e710:   2000 b487ec84 fe90d5a4 ff001e84
 
 Instructions: (pc=0xfee32868)
 0xfee32858:   12 40 00 08 90 10 20 00 d2 02 a0 04 d0 02 60 08
 0xfee32868:   ca 02 20 00 c8 01 60 30 9f c1 00 00 01 00 00 00
 
 Stack: [0xb480,0xb488),  sp=0xb487e6a0,  free space=505k
 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
 code)
 V  [libjvm.so+0x632868]
 V  [libjvm.so+0xf8884]
 V  [libjvm.so+0x1e3ba0]
 V  [libjvm.so+0x27f9f4]
 V  [libjvm.so+0x282748]
 V  [libjvm.so+0x278700]
 V  [libjvm.so+0x2793bc]
 V  [libjvm.so+0x335f28]
 V  [libjvm.so+0x2de2a4]
 V  [libjvm.so+0x664248]
 
 
 Current CompileTask:
 opto:1412  !  
 org.apache.lucene.index.IndexReader.open(Lorg/apache/lucene/store/Directory;Z)Lorg/apache/lucene/index/IndexReader;
 (36 bytes)
 
 
 ---  P R O C E S S  ---
 
 Java Threads: ( = current thread )
   0x001cd490 JavaThread TP-Processor24 daemon [_thread_blocked, id=64]
   0x009aa828 JavaThread TP-Processor23 daemon [_thread_in_native, id=63]
   0x0102e0d0 JavaThread TP-Processor22 daemon [_thread_in_native, id=62]
   0x006de9c0 JavaThread TP-Processor21 daemon [_thread_blocked, id=61]
   0x01bdf390 JavaThread TP-Processor20 daemon [_thread_in_native, id=60]
   0x004a5ce8 JavaThread TP-Processor19 daemon [_thread_in_native, id=59]
   0x00580af0 JavaThread TP-Processor18 daemon [_thread_blocked, id=58]
   0x006246d8 JavaThread TP-Processor17 daemon [_thread_in_native, id=57]
   0x01d7cb28 JavaThread TP-Processor16 daemon [_thread_blocked, id=56]
   0x0041f818 JavaThread TP-Processor15 daemon [_thread_in_native, id=55]
   0x00368598 JavaThread TP-Processor14 daemon [_thread_blocked, id=54]
   0x0191edb8 JavaThread TP-Processor13 daemon [_thread_in_native, id=53]
   0x00a45820 JavaThread TP-Processor12 daemon [_thread_in_native, id=52]
   0x01ba2d00 JavaThread TP-Processor11 daemon [_thread_in_native, id=51]
   0x01ba2b38 JavaThread TP-Processor10 daemon [_thread_blocked, id=50]
   0x00f67490 JavaThread TP-Processor9 daemon [_thread_in_native, id=49]
   0x00c352e8 JavaThread TP-Processor8 daemon [_thread_in_native, id=48]
   0x019a2118 JavaThread TP-Processor7 daemon [_thread_in_native, id=47]
   0x019dff78 JavaThread TP-Processor6 daemon [_thread_in_native, id=46]
   0x008aa3b0 JavaThread TP-Processor5 daemon [_thread_blocked, id=45]
   0x00e894d8 JavaThread TP-Monitor daemon [_thread_blocked, id=44]
   0x00e884e0 JavaThread TP-Processor4 daemon [_thread_in_native, id=43]
   0x00e87928 JavaThread TP-Processor3 daemon [_thread_in_native, id=42]
   0x0021ef40 JavaThread TP-Processor2 daemon [_thread_in_native, id=41]
   0x007696d8 JavaThread TP-Processor1 daemon [_thread_blocked, id=40]
   0x007683a0 JavaThread http-8080-Monitor [_thread_blocked, id=39]
   0x006570f0 JavaThread http-8080-Processor25 daemon 

Re: Help with filter affecting Chinese words in request parameters

2006-04-10 Thread Mark Hagger
Hi,

This may not be relevant here, but one standard gotcha that keeps
hitting me is a difference in the platforms default encoding.  Ie some
machines have a default of ISO-88591, some CP1252, and some UTF-8.  The
JVM then just merrily does stuff using the default encoding, and thus
developers get a working system and the production systems don't...

In some ways its better to have developers all working with different
defaults, so at least issues like this get caught early.

A thought anyway.

Mark


On Sun, 2006-04-09 at 22:53 -0500, Mike Sabroff wrote:
 So, what are the differences on the machines that have the problem vs 
 the ones that don not??
 
 roy tang wrote:
  Hi,
 
  I'm new to this list, hope someone here can help. :)
 
  We're developing a webapp that should be able to accept Chinese input. We
  also have a filter installed in the webapp for some auditing that we need to
  do per request that's processed. However, we've found that when we submit a
  form with Chinese inputs, the Chinese chars end up saved to the database as
  HTML-escaped entities. (i.e. #32610; or such).
 
  So we backtrace, and we find that removing the filter from web.xml fixes the
  problem. We debug through the doFilter() method of our filter, but we find
  that at the start of the method, request.getParameter(PARAM_NAME) already
  shows the input as HTML-escaped entities.
 
  The weird thing is, this doesn't happen on all our Tomcat
  installations...each of our developers has a local Tomcat running, and it
  only happens for one or two. But it also happens on our Test (QA) server,
  such that our testing team always encounters the problem.
 
  Is there any particular language or encoding setting that I should be
  checking?
 
  Thanks a lot :D
 
  Roy

 



This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: gc tuning

2006-03-29 Thread Mark Hagger
As I'm sure you know this is something of a large can of worms...

All I can say is that from my experience of this modern JVM's are getting much 
better at working well with the default gc options (ie jdk 5.0 and above).  
We use jrockit for our systems, and just use a simple:

-server -Xms256m -Xmx1024m

Our server are dual processor boxes with 6Gig ram and all runs well for us.  
From what I understand both current jrockit and sun gc strategies are to 
delay gc work until as late as possible (jrockit seems to leave it later than 
sun tbh).  This tends to mean that memory usage never really seems to drops 
much, our servers run with jrockit having grabbed around 1.9Gig memory all 
the time, but then seem to run happily with that for long periods of time (ie 
weeks at a time).  Both jrockit and sun default to adaptive gc systems for 
large systems, which ought to get to the right approach in due course.

Having said that experience suggests that if the application churns memory 
very fast (tomcat doesn't really qualify for that for us, but some of our 
other apps do), using a two generational concurrent gc approach is best, 
especially for jrockit.

The other thing to note is that a call to System.gc() does very little in some 
jvm's, I think its increasingly taken as a hint, and most gc's almost ignore 
it.  A real full gc is expensive and can cause heavy pauses, gc systems tend 
to avoid it like a plague.

Hope this is of some help, although I'd be interested to hear others thoughts 
on this.

Mark

On Wednesday 29 March 2006 19:17, John Powers wrote:
 I am trying to tune an instance of tomcat running a single application.
 And have a couple different questions.



 I have read lots of faqs and webpages on the various types of garbage
 collectors.   I get from most of these that it takes lots of tuning
 particular to each machine/server/application.



 My main question is why the memory allocated keeps climbing.If I
 have a fairly consistent number of users, then as some sessions are
 freed up, others are made.  Wouldn't the amount of allocated level off
 at some point? When a full GC is started, why does it never go back down
 to a low number?At night, lets say when there are no users, why
 wouldn't a GC drop the memory down to what is used by just the bare
 minimum?



 Most faqs and webpages say to allocate as much memory as possible.  How
 can you use the aggressiveHeap tag if tomcat is also trying to specify
 Mmx and Mms settings?   Does anyone have an example memory settings for
 a tomcat running on a 2-4 chip machine with around 2G of ram?



 I understand for a JSP application that we need to keep our permHeap
 size large.What do you guys normally do for that? 128M? 256M? 512M?



 Is it common that a tomcat needs restarting nightly to free up memory?
 In all my other apps I've had with tomcat, I've never needed to do that.
 I've been trying to use the profiler yourkit, but am uncertain what is a
 valid object in memory and what is being held on unnecessarily.



 Thanks for any help you can provide.






 
 This email has been scanned for all known viruses by the MessageLabs
 SkyScan service.


This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Access log to see where robots go.

2006-02-11 Thread Mark Hagger
robots.txt is a standard file that search engines should request before trying 
to index your site.  Its allows you to block the indexer completely, or 
partially from your site.  Try a google search for robots.txt for more 
details.

Not having one is the same as saying feel free to index my entire site, so 
in your case thats not causing any problems.

Mark


On Saturday 11 February 2006 16:57, Ed Bicker wrote:
 Hello Scott,
 I have had similar problem. Can you let me know if this is resolved on your
 end. Sometimes the email response coming back to me gets buried in another
 folder and I never get to see the resolutions.
 I can't seem to get search engines to see my site, as well. I do not know
 how to resolve this

 Thanks
 Ed
 [EMAIL PROTECTED]


 -Original Message-
 From: Scott Purcell [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 10, 2006 8:40 PM
 To: Tomcat Users List
 Subject: Access log to see where robots go.


 I have had trouble getting search engines to see my site. I built it with
 struts, and use some tags from the index.html page to get business logic,
 to finally get to my page. The url is http://www.theuniquepear.com

 Anyway, upon talking to some co-workers, they suggested I watch my access
 log, so I can see what files they are indexing. I thought I had the access
 log turned on for the site, and see when someone hits my web site, but as
 far as the searchbots go, I only see this in my logs daily.

 $ cat  localhost_access_log.2006-02-07.txt | less
 67.15.16.30 - - [07/Feb/2006:03:44:55 -0600] GET /robots.txt HTTP/1.0 404
 985
 67.15.16.30 - - [07/Feb/2006:03:46:21 -0600] GET / HTTP/1.0 200 844
 67.15.16.30 - - [07/Feb/2006:03:51:57 -0600] GET /robots.txt HTTP/1.0 404
 985
 62.114.208.233 - - [07/Feb/2006:03:52:42 -0600] GET
 /unique/welcome.do?OVRAW=home%20decorating%20ideasOVKEY=home
 62.114.208.233 - - [07/Feb/2006:03:52:44 -0600] GET
 /unique/includes/siteWide.css HTTP/1.1 200 15402
 62.114.208.233 - - [07/Feb/2006:03:52:44 -0600] GET
 /unique/images/header_pear.jpg HTTP/1.1 200 11227


 I see the entry for robots.txt, but I have no idea where they are going, or
 what they are doing.

 I turned on access log like this in the server.xml like so:
 Valve className=org.apache.catalina.valves.AccessLogValve
  directory=logs  prefix=localhost_access_log.
 suffix=.txt
  pattern=common resolveHosts=false/

 And that is a snippet of the log from above.

 Does anyone know how to get more involved text, or can anyone tell me what
 the robots.txt above is doing?


 Thanks,
 Scott


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 This email has been scanned for all known viruses by the MessageLabs
 SkyScan service.


This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Image Scaling Code

2006-01-12 Thread Mark Hagger
You need to have:

-Djava.awt.headless=true

in your java start up args, this will prevent it from trying to talk to an X 
server.  Obviously some image related stuff has to talk to an X server, but 
just ImageIO stuff is fine.

Mark


On Thursday 12 January 2006 19:31, Frank W. Zammetti wrote:
 I don't quite see how this is Tomcat-related, but...

 Your code can't connect to your X server, which is necessary for many
 Java graphics-related functions to work on a *nix system.  I dealt with
 this at one point when getting DataVision working on Linux, and I recall
 the solution being something to do with an environment variable, but the
 exact answer eludes me.

 Actually, it looks like you *have* defined the environment variable
 (DISPLAY in the stack trace rings a bell).  Is X running?  I believe it
 has to be for this to work.

 Frank

 Justin Jaynes wrote:
  Hello all,
 
   I've written a java class to scale jpeg images.  But I can't seem to get
  it to work.  Can anyone point me in the right direction?
 
   Here is my code:
 
 
  package com.everybuddystree;
 
  import java.awt.*;
  import java.awt.image.*;
  import java.io.*;
  import javax.imageio.*;
 
  public class ImageScaler {
 
   public ImageScaler() {
   }
 
   public boolean scaleImageByWidth(String fileName, int newWidth) {
 
File originalImage = new File(fileName);
try {
 BufferedImage workingBufferedImage = ImageIO.read(originalImage);
 int width = workingBufferedImage.getWidth();
 int height = workingBufferedImage.getHeight();
 Image workingImage = workingBufferedImage;
 workingImage = (Image)workingImage.getScaledInstance(newWidth,-1,1);
 BufferedImage finalImage = (BufferedImage)workingImage;
 ImageIO.write(finalImage, jpg, originalImage);
 
 return true;
 
} catch (IOException ex){
 
 return false;
 
}
 
   }
 
  }
 
  When I run the pass an image to the class using a jsp I get the
  following errors from Tomcat:
 
 
   HTTP Status 500 -
  -
   type Exception report
   message
   description The server encountered an internal error () that prevented
  it from fulfilling this request. exception
   javax.servlet.ServletException: Can't connect to X11 window server using
  ':0.0' as the value of the DISPLAY variable. 
  org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageConte
 xtImpl.java:848) 
  org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContext
 Impl.java:781) 
  org.apache.jsp.image_jsp._jspService(org.apache.jsp.image_jsp:158) 
  org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 
  org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.jav
 a:322) 
  org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) 
  org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause
  java.lang.InternalError: Can't connect to X11 window server using ':0.0'
  as the value of the DISPLAY variable. 
  sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) 
  sun.awt.X11GraphicsEnvironment.access$000(X11GraphicsEnvironment.java:53)
   sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:142) 
  java.security.AccessController.doPrivileged(Native Method) 
  sun.awt.X11GraphicsEnvironment.clinit(X11GraphicsEnvironment.java:131) 
  java.lang.Class.forName0(Native Method) 
  java.lang.Class.forName(Class.java:164) 
  java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironm
 ent.java:68)  sun.awt.X11.XToolkit.clinit(XToolkit.java:96) 
  java.lang.Class.forName0(Native Method) 
  java.lang.Class.forName(Class.java:164) 
  java.awt.Toolkit$2.run(Toolkit.java:821) 
  java.security.AccessController.doPrivileged(Native Method) 
  java.awt.Toolkit.getDefaultToolkit(Toolkit.java:804) 
  java.awt.Image.getScaledInstance(Image.java:158)
  com.everybuddystree.ImageScaler.scaleImageByWidth(ImageScaler.java:21) 
  org.apache.jsp.image_jsp._jspService(org.apache.jsp.image_jsp:114) 
  org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 
  org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.jav
 a:322) 
  org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) 
  org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:802) note The
  full stack trace of the root cause is available in the Apache
  Tomcat/5.5.12 logs.
 
  -
   Apache Tomcat/5.5.12
 
 
 
 
 
 
  -
  Yahoo! Photos – Showcase holiday pictures in hardcover
   Photo Books. You design it and we’ll bind it!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For 

asynchronous vs fastasyncqueue

2006-01-09 Thread Mark Hagger
Hi,

I'm a little confused as to the difference between the asynchronous and
fastasyncqueue cluster replication types.

We're currently using asynchronous, our application only really needs
replication to minimise the impact on users if a server dies, ie its not
a hard requirement, I certainly don't want to allow replication to have
any noticeable impact on response times, which is the bottom line in our
application.

However, I can't quite work out if fastasyncqueue is better in some way.
Is it just an alternative implementation of asynchronous?  Is it the
future of async type replications?  Does it have a lower
memory/performance impact, better throughput or what?

Any enlightenment, or indeed some performance figures if anyone has
them, would be useful.

Regards,

Mark

-- 
Mark Hagger
[EMAIL PROTECTED]




This email has been scanned for all known viruses by the MessageLabs SkyScan 
service.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]