Re: newbie logging question: JULI or log4j or both?
Thanks for following up Charles. I have one more question about catalina.* logs. I made some changes in my webapps config (snippet below) and I got logs in catalina.out as well as in a file specified by FileAppender. The problem seems to be because of my wrong config where I used CONSOLE appender as well FILE appender; and hence I got logs in catalina.out as well as specified file. As you explained Stdout goes to catalina.out, so this was expected. But I see some inconsistency in the $CATALINA_HOME/logs directory. I see catalina.out as well as catalina..log . But the catalina..log file is not in sync with catalina.out, e.g. Sum of( catalina..log ) != catalina.out file . For certain days I see logs in catalina.out but there is no catalina..log file for that day. I don't think those files got deleted, so I am wondering what is wrong with the configuration? Any help on what to look for catalina.* log configuration? Am I missing something over here? -- jM. Following were config changes to add log4j: * Edited $CATALINA_HOME/webapps/WReports/web.xml log4jConfigLocation /WEB-INF/classes/log4j.xml org.springframework.web.util.Log4jConfigListener * Edited $CATALINA_HOME/webapps/WReports/WEB-INF/classes/log4j.xml which contains appender and logger config. Omitted unnecessary(?) part: -- Forwarded message -- From: Caldarale, Charles R Date: Fri, May 21, 2010 at 5:32 PM Subject: RE: newbie logging question: JULI or log4j or both? To: Tomcat Users List > From: Johan Martinez [mailto:jmart...@gmail.com] > Subject: Re: newbie logging question: JULI or log4j or both? > > Tomcat was not installed using CentOS package manager, but it > is a core binary package downloaded from tomcat project site. Good; that means we don't have to guess what any repackager fiddled with. > * $CATALINA_HOME/common/classes/log4j.properties: > contains a line which is spitting out logs to tomcat.log > So I guess I am using log4j for internal logging and they > are going to tomcat.log file. Sounds like it. Looks like someone has modified the Tomcat installation in accordance with these instructions: http://tomcat.apache.org/tomcat-5.5-doc/logging.html#log4j > I don't see any configuration that specifies catalina.out. There won't be - that's specified only in the startup script as a redirect from stdout. - 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: newbie logging question: JULI or log4j or both?
> From: Johan Martinez [mailto:jmart...@gmail.com] > Subject: Re: newbie logging question: JULI or log4j or both? > > Tomcat was not installed using CentOS package manager, but it > is a core binary package downloaded from tomcat project site. Good; that means we don't have to guess what any repackager fiddled with. > * $CATALINA_HOME/common/classes/log4j.properties: > contains a line which is spitting out logs to tomcat.log > So I guess I am using log4j for internal logging and they > are going to tomcat.log file. Sounds like it. Looks like someone has modified the Tomcat installation in accordance with these instructions: http://tomcat.apache.org/tomcat-5.5-doc/logging.html#log4j > I don't see any configuration that specifies catalina.out. There won't be - that's specified only in the startup script as a redirect from stdout. - 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: set-cookie
> From: banto [mailto:banto...@gmail.com]
> Subject: set-cookie
>
> Now the code is something like:
>
> public class FrontController extends HttpServlet {
>
> public void init() throws ServletException {
>
> HashMap products = new HashMap();
> Product p = new Product(1, "Dog", "9.99");
> products.put("1", p);
> // Store products in the ServletContext
> getServletContext().setAttribute("products", products);
> }
> public void doPost(HttpServletRequest request,
> HttpServletResponse
> response)
> .
It's the code in the doXxx() methods that needs examination, not the init()
method. Do you have any JSPs? IIRC, these will automatically create a session
unless explicitly disabled.
- 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.
RE: set-cookie
> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: set-cookie
>
> // Store products in the ServletContext
> getServletContext().setAttribute("products", products);
>
> Presumably, if you store something in the context, it is because you
> want to retrieve it later (or else, what's the point he ?).
> Now, Tomcat has no way to know when you'll come back to retrieve it, so
> it has to create a session to store this.
Nope, that's not it (but I don't know what is, yet). Attributes stored in a
ServletContext have a webapp, not session, scope; no session is needed here,
and nothing needs to be communicated between the client and server to retrieve
them.
- 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.
Re: newbie logging question: JULI or log4j or both?
Thanks for the reply Charles. It's a CentOS 5.4 system with Sun JDK 1.5 and tomcat-5.5.28 version. Tomcat was not installed using CentOS package manager, but it is a core binary package downloaded from tomcat project site. I downloaded a fresh copy of tomcat package and took a diff of it against tomcat in-use. Attached below is a snippet of it. On further digging around I found following configuration related to logs: * $CATALINA_HOME/common/classes/log4j.properties: contains a line which is spitting out logs to tomcat.log So I guess I am using log4j for internal logging and they are going to tomcat.log file. * $CATALINA_HOME/conf/logging.properties I don't see any configuration that specifies catalina.out. But the reason I see logs in catalina.out are because of following reasons: ** Tomcat startup/shutdown information that goes to Stdout and Stderr ** My lazy programming practice: Not using log4j or any other logging API. Am I understanding it correctly? Any thoughts? Thanks, jM. Tomcat diff: diff -r --exclude=logs --exclude=webextapps --exclude=temp ./apache-tomcat-5.5.28/bin/catalina.sh /home/testWbs/extapps/apache-tomcat-5.5.28/bin/catalina.sh 166c166 < JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" --- > JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -Xms128m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m" Only in /home/testWbs/extapps/apache-tomcat-5.5.28/common/classes: log4j.properties Only in /home/testWbs/extapps/apache-tomcat-5.5.28/common/lib: commons-logging-1.1.jar Only in /home/testWbs/extapps/apache-tomcat-5.5.28/common/lib: log4j-1.2.14.jar diff -r --exclude=logs --exclude=webextapps --exclude=temp ./apache-tomcat-5.5.28/conf/logging.properties /home/testWbs/extapps/apache-tomcat-5.5.28/conf/logging.properties 45c45,46 < java.util.logging.ConsoleHandler.level = FINE --- > #java.util.logging.ConsoleHandler.level = FINE > java.util.logging.ConsoleHandler.level = DEBUG On Thu, May 20, 2010 at 10:54 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Johan Martinez [mailto:jmart...@gmail.com] > > Subject: newbie logging question: JULI or log4j or both? > > > > I am a developer and new to tomcat administration. > > Tomcat version? JVM version? Platform? > > (Always provide the basics when making inquiries.) > > > How do I find out if I am using JULI or log4j for logging? > > Tomcat logging and webapp logging are independent; you may well be using > both, perhaps JULI for Tomcat and log4j for one or more webapps. Where are > the configuration files located? > > > Also, I see logs in catalina.out and tomcat.log. > > Standard, supported versions of Tomcat do not normally produce any file > named "tomcat.log"; if you've got one, someone has fiddled with the default > logging configuration, or you're running a 3rd-party repackaged version of > Tomcat. > > The catalina.out file is usually just a redirection of stdout and stderr, > and normally only appears on Linux/UNIX systems. If webapps are writing to > it, then the authors of the webapp were too lazy to utilize a proper logging > mechanism. > > > I would like to customise it with DailyRollingFile, but I don't > > see it mentioned anywhere. > > Look in the startup script you're using to get Tomcat running. > > You might want to read through the FAQ entries on logging: > http://wiki.apache.org/tomcat/FAQ/Logging > > - 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: set-cookie
banto wrote:
Hi gurus,
my problem here is that i'm trying to understnad a servlet code that makes
tomcat to send the
Set-Cookie: JSESSIONID=8BCB60D6F6B9394B4ABD2FDD007BDB39; Path=/store
header.
Now the code is something like:
public class FrontController extends HttpServlet {
public void init() throws ServletException {
HashMap products = new HashMap();
Product p = new Product(1, "Dog", "9.99");
products.put("1", p);
// Store products in the ServletContext
getServletContext().setAttribute("products", products);
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)
.
and the web.xml is quite standard.
my problem is that i don´t see where the servlet is instructing tomcat to
sent that header.
I would guess right here :
// Store products in the ServletContext
getServletContext().setAttribute("products", products);
Presumably, if you store something in the context, it is because you
want to retrieve it later (or else, what's the point he ?).
Now, Tomcat has no way to know when you'll come back to retrieve it, so
it has to create a session to store this. And to allow you to get that
same session data back later (and not someone else's data), it has to
create some unique key for it. And if you have to be able to get that
data later, you need this key. So Tomcat is nice and sends it to you,
inside of a cookie. This way, you do not need to remember to send the
key back when you next come around, your browser will do it
automatically for you.
Neat, he ?
My other servlets are not issuing that header when running. So what i´m
missing?
Probably, because they do not store anything in their context.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Keeping tomcat up-to-date on linux
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 5/20/2010 6:40 PM, André Warnier wrote: Dale Ogilvie wrote: ... A free gift can vary greatly in it's final value, depending on it's actual usefulness and how many hidden costs it brings with it. I think that now you are *really* pushing it. People have been blacklisted from this list, and have had their Tomcat download license revoked for less than that. Please be sure that André is kidding about being blacklisted, etc. I figured the "tomcat download license" made that pretty clear, but he.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
set-cookie
Hi gurus,
my problem here is that i'm trying to understnad a servlet code that makes
tomcat to send the
Set-Cookie: JSESSIONID=8BCB60D6F6B9394B4ABD2FDD007BDB39; Path=/store
header.
Now the code is something like:
public class FrontController extends HttpServlet {
public void init() throws ServletException {
HashMap products = new HashMap();
Product p = new Product(1, "Dog", "9.99");
products.put("1", p);
// Store products in the ServletContext
getServletContext().setAttribute("products", products);
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)
.
and the web.xml is quite standard.
my problem is that i don´t see where the servlet is instructing tomcat to
sent that header.
My other servlets are not issuing that header when running. So what i´m
missing?
thanks you!!
--
View this message in context:
http://old.nabble.com/set-cookie-tp28639362p28639362.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
question for singlesignon for vertical cluster
Hi I would like to enable singlesignon on vertical cluster environment [multi-nodes on multiple hosts]. We are using clustersinglesignon under host element, and this works in horizontal cluster, but does not work in vertical cluster environment. Is there any way to make this work as part of tomcat configuration? When the node goes down, and a user may be routed to the node located in a different host, it will ask a user to relogin again under the current setup. We would like to avoid a user for relogging to the application. Thanks, yasushi - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsessionid problem
Hi Chris, Thanks for your mail. Actually we were analysing our proxy server logs and saw that a lot of URLs with jsessionid appended were being cached and this even includes static files. We saw request for static files like images and .js files being appended with jsessionid. So i think it happens for more than a few pages. Thanks On Fri, May 21, 2010 at 5:25 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Richard, > > On 5/21/2010 11:45 AM, Richard Nduka wrote: > > Secondly, we have not disabled cookies. In our context, we have cookies > set > > to true and cookie is enabled in the browser. For some reason, tomcat > still > > re-writes the URL and includes the jsessionid. > > Does this happen to all URLs throughout the application, or only certain > ones? Is Tomcat also sending Set-Cookie headers to the client? Is the > client actually sending Cookie headers to the server? > > During the first request/response conversation between the client and > the server, it's often impossible for the server to tell if the client > can support cookies, and so it does both: Set-Cookie in the response, > plus, all the URLs are rewritten with the jsessionid parameter appended > to them. > > Once the client sends a second request, the cookie is included and the > remaining responses do not have URLs rewritten. > > If you need to remove that corner case, as well as disable all cookies > who do not support cookies, you'll have to write a simple filter that > wraps the response and overrides the encodeURL and encodeRedirectURL > methods (and their older, misspelled versions, too) so that they return > unmodified URLs. This may have ... unintended consequences where > sessions and cookie-less clients are concerned, though. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkv2tBQACgkQ9CaO5/Lv0PDGtACgoRD0PJWBUwRbSydbdRvFCc9u > /UgAnAhQKVqHQ7V8k1rSIAIIF7Dpf49f > =sb0u > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Way to record what URL an error originated from in my localhost file?
Hi Chris,
Thanks for this suggestion. Just to be sure I'm understanding correctly,
the procedure would be
1. Add an error-page element to my xml doc that will be visited whenever an
exception is generated from my JSP or servlet.
2. Configure valve to output a stack trace and the original request URI that
generated the error.
Is that right? Also is valve smart enough to understand that I don't want
to see "500.jsp" in my log file but rather something like
"search_results.jsp?category=1" ?
Thanks again, - Dave
Christopher Schultz-2 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dave,
>
> On 5/20/2010 5:30 PM, laredotornado wrote:
>> Is there a way to configure Tomcat to record what the URL was in the
>> browser
>> when this error occurred?
>
> Do you have any elements in your web.xml? Do you have
> custom error pages? If you do, the best place to put this kind of stuff
> is in your custom error pages - if they are either JSPs or some other
> dynamic resource.
>
> See section 9.9 of the servlet spec, and you'll find that you can obtain
> the original URL and other interesting information using request
> attributes:
>
> javax.servlet.error.status_code
> javax.servlet.error.exception_type
> javax.servlet.error.message
> javax.servlet.error.exception
> javax.servlet.error.request_uri
> javax.servlet.error.servlet_name
>
>> While I'm at it, is there a way to also link in
>> all session and request data at the time of the error (since the request
>> may
>> have been submitted via HTTP POST)?
>
> The best thing for you to do is manually dump that information when an
> error occurs. I suppose there's the possibility that you could set up an
> AccessLogValve that only logs when an error occurs:
>
> ... [file and path parameters] ...
>condition="javax.servlet.error.request_uri"
>pattern="[%t] %a %{javax.servlet.error.request_uri}r (no CRLF)
> %{my.session.attribute}s (no CRLF here, either)
> %{my.other.session.attribute}s" />
>
> See the documentation for AccessLogValve to see what all those setting
> mean.
>
> This can't dump the /entire/ session, but it can dump pre-defined
> session attributes. It also can't dump the non-GET request parameters.
>
> If you want to look at ExtendedAccessLogValve, it can do some more
> exciting things, though I think you have to know the parameter names
> beforehand: it can't simply dump the entire set of request parameters.
>
> Hope that helps,
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkv1uOoACgkQ9CaO5/Lv0PD3UQCfS3J7W0kcs+UVKkl4+5nqIfCS
> RcEAn0G+pD9BgeOIkITbZmz/0fJk9n4D
> =shmH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
--
View this message in context:
http://old.nabble.com/Way-to-record-what-URL-an-error-originated-from-in-my-localhost-file--tp28626297p28638705.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: [OT] Tomcat 6.0.20 is running out of memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 5/21/2010 8:27 AM, André Warnier wrote: > Pid wrote: >> On 21/05/2010 12:57, kent.anders...@tieto.com wrote: >>> Hi, >>> >>> We are running Jakarta Tomcat Servlet/JSP Engine 6.0.20 > > on Solaris 2.10. > > That may have been a 16-bit version. Heh. I think this version really means "Solaris 10". Sun can't stop re-numbering its OS releases. "Solaris 10" (which was released after 9, 8, 7, and 2.6) was released in 2005, so it should be relatively up-to-date. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv201gACgkQ9CaO5/Lv0PAuXgCgn0+baizS8+hFyxeXQ5AWw2Yl 27YAoIPRva9MAXlCpsA6zqLmCkq9OHHf =xcKu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.20 is running out of memory
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: Tomcat 6.0.20 is running out of memory > > MaxHeap=128MiB and MaxNewSize=4GiB? That doesn't look right > to me. It's fine. Newer JVMs automatically set MaxNewSize to a nearly infinite value. (In other words, it's not really used any more.) - 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.
Re: Tomcat 6.0.20 is running out of memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kent, On 5/21/2010 8:25 AM, kent.anders...@tieto.com wrote: > Heap Configuration: >MinHeapFreeRatio = 40 >MaxHeapFreeRatio = 70 >MaxHeapSize = 134217728 (128.0MB) >NewSize = 2228224 (2.125MB) >MaxNewSize = 4294901760 (4095.9375MB) Wait, what? MaxHeap=128MiB and MaxNewSize=4GiB? That doesn't look right to me. Other than that, your heap looks good. Is this before or after you get the OOME? If it's before, try repeating this after you get the OOME and re-post. Can you describe the circumstances under which you get the OOME? Do you, for instance, run just fine for a long time and then it bombs? Or does it bomb on the first page access? Or, does it only bomb after you've auto-re-loaded your webapp several times? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv20o4ACgkQ9CaO5/Lv0PA9owCeLBERN8ymw2JblZVyx8kPfGrF bvwAoKMdWRd20XcG6ehyIwNtI6/ZqqTh =zF92 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 6.0.20 is running out of memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kent, On 5/21/2010 6:57 AM, kent.anders...@tieto.com wrote: > java.lang.OutOfMemoryError: Java heap space > [...] > at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) > at org.apache.jasper.compiler.Localizer.(Localizer.java:36) > at org.apache.jasper.runtime.PageContextImpl.release > (PageContextImpl.java:191) > at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext > (JspFactoryImpl.java:118) > at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext > (JspFactoryImpl.java:77) Funny that TC is running out of heap space while trying to free resources... Any reason that TC is creating a new Localizer object in this method? Seems to be counter-intuitive... - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv20bsACgkQ9CaO5/Lv0PAXxwCfRTti4lKiErXBDvqZtQJMvRSH r8MAn0otRlEL7hAllOagBFUsxKBJv90v =SolY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsessionid problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard, On 5/21/2010 12:07 PM, Richard Nduka wrote: > Thanks again for your reply. > > 1. We are not using clustering. > > 2. I have checked in the locations mentioned and more and cannot see > anywhere that cookies is disabled. > > 3. However what surprises me is the fact that if i change the port to use > HTTP (8080) then no jsessionid is appended in the URL but if i change to > HTTPS (8443) then it is appended. You are probably observing that a (possibly secure-only) cookie already exists for the secure server and therefore Tomcat already knows that cookies are supported by the client. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv20PQACgkQ9CaO5/Lv0PCU/wCgqRngtWcdVkkebqdJenhuIc7s YrMAoJew6yCd5mTOybTRJAUSPvdYz3El =HBDq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsessionid problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard, On 5/21/2010 11:45 AM, Richard Nduka wrote: > Secondly, we have not disabled cookies. In our context, we have cookies set > to true and cookie is enabled in the browser. For some reason, tomcat still > re-writes the URL and includes the jsessionid. Does this happen to all URLs throughout the application, or only certain ones? Is Tomcat also sending Set-Cookie headers to the client? Is the client actually sending Cookie headers to the server? During the first request/response conversation between the client and the server, it's often impossible for the server to tell if the client can support cookies, and so it does both: Set-Cookie in the response, plus, all the URLs are rewritten with the jsessionid parameter appended to them. Once the client sends a second request, the cookie is included and the remaining responses do not have URLs rewritten. If you need to remove that corner case, as well as disable all cookies who do not support cookies, you'll have to write a simple filter that wraps the response and overrides the encodeURL and encodeRedirectURL methods (and their older, misspelled versions, too) so that they return unmodified URLs. This may have ... unintended consequences where sessions and cookie-less clients are concerned, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2tBQACgkQ9CaO5/Lv0PDGtACgoRD0PJWBUwRbSydbdRvFCc9u /UgAnAhQKVqHQ7V8k1rSIAIIF7Dpf49f =sb0u -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] how to return a zipped file so that the browser will unzip it ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 5/20/2010 5:16 PM, André Warnier wrote: > Christopher Schultz wrote: > ... >> >> I wonder if a patch could be written for the DefaultServlet to do >> something like this: if compression has been enabled on the , >> the request is for file "foo", and "foo.gz" exists in the same location, >> use the "foo.gz" file as source instead of compressing on the fly. > > That is precisely what I was thinking of. > Of course I would not even dream of even attempting myself to patch the > DefaultServlet code.. The requirements for such a patch would need to be well-specified. Otherwise, you might have a security problem on your hands (DefaultServlet serves files other than those requested? This could be construed as a way around the s in web.xml). I think a Filter is the right way to do things for the time being. In fact, you could even have the filter wrap the original request and tell the DefaultServlet that the filename is different. That way, you don't have to write your own stream-copying code, and things like "Range" headers should still work, but things get hairy with "Range" and not-so-transparent compression :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2skYACgkQ9CaO5/Lv0PBeXQCeLIVTzZwNCBey6BGS9pVKFBv4 aqsAoJfk8iEVAWAqzOoMTwWADK5sA0u3 =A+vp -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsessionid problem
On 21/05/2010 17:09, Richard Nduka wrote: > It is a direct request. Typically, it happens for the first time when a user > enters the application url in a browser and the login page appears with the > jsessionid appended in the url. That is expected. Tomcat doesn't know if the browser supports cookies at that point so it tries both. Once it knows cookies work, it will drop the path paramater. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user cancels download attachment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ðavîd, On 5/20/2010 10:08 PM, Ðavîd Låndïs wrote: > OK I'll investigate a little more at work tomorrow. I'm hoping the > issue isn't that Tomcat is swallowing the exceptions somewhere. Tomcat is very unlikely to swallow such exceptions. > Incidentally, does anyone know what exception is supposed to be thrown > when a user cancels the attachment download? What if you try a simple test: write a test servlet that generates a ton of output: multiple megabytes. Write to the response's OutputStream (instead of the Writer). Cancel that while it's downloading and see if you get an exception. It may just be that PrintWriter is ruining your day, here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2sRUACgkQ9CaO5/Lv0PC4YwCeI7RIEumQ3GorZ8zszcFh2Kc1 DPEAoIpG9pwtAG57SM3LlIwI4YwrDIlm =ucrD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsessionid problem
It is a direct request. Typically, it happens for the first time when a user enters the application url in a browser and the login page appears with the jsessionid appended in the url. Thanks. On Fri, May 21, 2010 at 5:05 PM, Pid wrote: > On 21/05/2010 16:59, Caldarale, Charles R wrote: > >> From: Richard Nduka [mailto:richies4...@gmail.com] > >> Subject: Re: jsessionid problem > > > >> First of all, we are not fronting tomcat with any other web server or > >> application server apart from the proxy server (Squid) that seats in > >> front of tomcat. > > > > Are you using clustering? > > > >> Secondly, we have not disabled cookies. > > > > You might want to double check that. You'll need to look in > conf/context.xml, the webapp's META-INF/context.xml, and > conf/Catalina/[host]/[appName].xml for starters. > > > >> In our context, we have cookies set to true > > > > Which is the default. > > > >> For some reason, tomcat still re-writes the URL and > >> includes the jsessionid. > > What kind of client is making the request that is rewritten? > > Is the request referred from a link in a page, or is it a direct request? > > > p > > >> Tomcat version: 5.5.23 > > > > That version is over three years old; you might want to move up to the > current 5.5.29 and see if the problem persists. A change to jsessionid > handling did go into 5.5.26, but it appears to deal with incoming jsessionid > values, not outgoing. > > > > - 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: Keeping tomcat up-to-date on linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 5/20/2010 6:40 PM, André Warnier wrote: > Dale Ogilvie wrote: >> > ... >> >> A free gift can vary greatly in it's final value, depending on it's >> actual usefulness and how many hidden costs it brings with it. >> > I think that now you are *really* pushing it. People have been > blacklisted from this list, and have had their Tomcat download license > revoked for less than that. Please be sure that André is kidding about being blacklisted, etc. Since we're on proverbs, you might not want to bite the hand that feeds, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2sAwACgkQ9CaO5/Lv0PDg9QCgwjy9atK1mCk6Uiuz3O2neUiB D90Anj5WrMFdq+PYYfwad7tPz39rb/BH =sTxF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jsessionid problem
Thanks again for your reply. 1. We are not using clustering. 2. I have checked in the locations mentioned and more and cannot see anywhere that cookies is disabled. 3. However what surprises me is the fact that if i change the port to use HTTP (8080) then no jsessionid is appended in the URL but if i change to HTTPS (8443) then it is appended. Thanks. On Fri, May 21, 2010 at 4:59 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Richard Nduka [mailto:richies4...@gmail.com] > > Subject: Re: jsessionid problem > > > First of all, we are not fronting tomcat with any other web server or > > application server apart from the proxy server (Squid) that seats in > > front of tomcat. > > Are you using clustering? > > > Secondly, we have not disabled cookies. > > You might want to double check that. You'll need to look in > conf/context.xml, the webapp's META-INF/context.xml, and > conf/Catalina/[host]/[appName].xml for starters. > > > In our context, we have cookies set to true > > Which is the default. > > > For some reason, tomcat still re-writes the URL and > > includes the jsessionid. > > > > Tomcat version: 5.5.23 > > That version is over three years old; you might want to move up to the > current 5.5.29 and see if the problem persists. A change to jsessionid > handling did go into 5.5.26, but it appears to deal with incoming jsessionid > values, not outgoing. > > - 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: jsessionid problem
On 21/05/2010 16:59, Caldarale, Charles R wrote: >> From: Richard Nduka [mailto:richies4...@gmail.com] >> Subject: Re: jsessionid problem > >> First of all, we are not fronting tomcat with any other web server or >> application server apart from the proxy server (Squid) that seats in >> front of tomcat. > > Are you using clustering? > >> Secondly, we have not disabled cookies. > > You might want to double check that. You'll need to look in > conf/context.xml, the webapp's META-INF/context.xml, and > conf/Catalina/[host]/[appName].xml for starters. > >> In our context, we have cookies set to true > > Which is the default. > >> For some reason, tomcat still re-writes the URL and >> includes the jsessionid. What kind of client is making the request that is rewritten? Is the request referred from a link in a page, or is it a direct request? p >> Tomcat version: 5.5.23 > > That version is over three years old; you might want to move up to the > current 5.5.29 and see if the problem persists. A change to jsessionid > handling did go into 5.5.26, but it appears to deal with incoming jsessionid > values, not outgoing. > > - 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 > signature.asc Description: OpenPGP digital signature
RE: jsessionid problem
> From: Richard Nduka [mailto:richies4...@gmail.com] > Subject: Re: jsessionid problem > First of all, we are not fronting tomcat with any other web server or > application server apart from the proxy server (Squid) that seats in > front of tomcat. Are you using clustering? > Secondly, we have not disabled cookies. You might want to double check that. You'll need to look in conf/context.xml, the webapp's META-INF/context.xml, and conf/Catalina/[host]/[appName].xml for starters. > In our context, we have cookies set to true Which is the default. > For some reason, tomcat still re-writes the URL and > includes the jsessionid. > > Tomcat version: 5.5.23 That version is over three years old; you might want to move up to the current 5.5.29 and see if the problem persists. A change to jsessionid handling did go into 5.5.26, but it appears to deal with incoming jsessionid values, not outgoing. - 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: jsessionid problem
Hi Chuck/Peter, Thanks guys for your mail. First of all, we are not fronting tomcat with any other web server or application server apart from the proxy server (Squid) that seats in front of tomcat. Secondly, we have not disabled cookies. In our context, we have cookies set to true and cookie is enabled in the browser. For some reason, tomcat still re-writes the URL and includes the jsessionid. Tomcat version: 5.5.23 Platform: Linux JDK: 1.6 Thanks. Richard. On Fri, May 21, 2010 at 4:27 PM, Peter Crowther wrote: > On 21 May 2010 16:16, Caldarale, Charles R >wrote: > > > > From: Richard Nduka [mailto:richies4...@gmail.com] > > > Subject: jsessionid problem > > > > > > I have a few quesations i want to ask about jessionid in tomcat. > > > > Thanks for asking twice - two minutes apart. A tad impatient, are we? > > > > Also too impatient to mention the Tomcat version, JVM you're using, > > platform you're running on, and whether or not you're front-ending Tomcat > > with something like httpd or IIS? > > > > *chuckle* The second one of the two had versions appended, Chuck - so there > was extra information there. > > - Peter >
Re: jsessionid problem
On 21 May 2010 16:16, Caldarale, Charles R wrote: > > From: Richard Nduka [mailto:richies4...@gmail.com] > > Subject: jsessionid problem > > > > I have a few quesations i want to ask about jessionid in tomcat. > > Thanks for asking twice - two minutes apart. A tad impatient, are we? > > Also too impatient to mention the Tomcat version, JVM you're using, > platform you're running on, and whether or not you're front-ending Tomcat > with something like httpd or IIS? > *chuckle* The second one of the two had versions appended, Chuck - so there was extra information there. - Peter
RE: jsessionid problem
> From: Richard Nduka [mailto:richies4...@gmail.com] > Subject: jsessionid problem > > I have a few quesations i want to ask about jessionid in tomcat. Thanks for asking twice - two minutes apart. A tad impatient, are we? Also too impatient to mention the Tomcat version, JVM you're using, platform you're running on, and whether or not you're front-ending Tomcat with something like httpd or IIS? > 1. In our web based application which runs on HTTPS, we > have observed that the jsessionid is being appended to > the URL. So stop disabling cookies, and it won't do that. If the client is refusing to use cookies, there's nothing you can do about it, other than not talk to them. If you have disabled cookies in the element for your webapp, don't do that. http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - 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: jsessionid problem
Richard, there are two ways of maitaining sessions: 1) Using cookies (generally Tomcat's preferred way); 2) Using URL rewriting (generally Tomcat's less preferred way, used where a client has turned off cookies). There are no other ways of sending session IDs that are supported by all Web browsers across all content types, though I could conceive of some extra ones if you were using AJAX. Remember that the browser has to know to send the session ID back to the server with the next request; this can only be done using cookies or some feature of the URL. All that said, I'm surprised Tomcat isn't using cookies in your case. Have you turned them off in the browser? Have you turned on the use of URL rewriting in the webapp's config? - Peter On 21 May 2010 16:06, Richard Nduka wrote: > Hi, > > I have a few quesations i want to ask about jessionid in tomcat. > > 1. In our web based application which runs on HTTPS, we have observed that > the jsessionid is being appended to the URL. On close examination, we have > observed that this is being added by tomcat to the url (Handled by the > encodeRedirectURL method in Response.java object in the tomcat sources). > Why > does tomcat do this? > > 2. Is it possible for this to be included in the response headers rather > than in the URL? If possible, how can one go about doing this? > > Thanks in advance. >
Re: jsessionid problem
Hi, I have a few quesations i want to ask about jessionid in tomcat. 1. In our web based application which runs on HTTPS, we have observed that the jsessionid is being appended to the URL. On close examination, we have observed that this is being added by tomcat to the url (Handled by the encodeRedirectURL method in Response.java object in the tomcat sources). Why does tomcat do this? 2. Is it possible for this to be included in the response headers rather than in the URL? If possible, how can one go about doing this? Tomcat Version: 5.5.23 Platform: Linux JDK version: 1.6 Thanks in advance.
jsessionid problem
Hi, I have a few quesations i want to ask about jessionid in tomcat. 1. In our web based application which runs on HTTPS, we have observed that the jsessionid is being appended to the URL. On close examination, we have observed that this is being added by tomcat to the url (Handled by the encodeRedirectURL method in Response.java object in the tomcat sources). Why does tomcat do this? 2. Is it possible for this to be included in the response headers rather than in the URL? If possible, how can one go about doing this? Thanks in advance.
Re: disable caching of static files in tomcat 5.5
On 21/05/2010 15:22, haveaguess wrote: > > Ive got the same problem - did anyone figure out what is happening and why > tomcat is caching files behind symlinks? This thread is 9 months old. You might consider starting a new thread, be specific about your versions & platform. p > Epithemeus wrote: >> >> Thanks Mark. >> >> I went through the documentation but the problem persists. I am using >> Tomcat 6.0 and have tried including cachingAllowed="false" in >> $CATALINA_HOME/conf/context.xml. This does not seem to work. >> >> There is no other context.xml file currently defined in directory >> structure anywhere. Any ideas on why this still isn't working? >> >> Thanks. >> >> >> Mark Thomas-18 wrote: >>> >>> Epithemeus wrote: Hi Joerg, I am facing the same issue with Tomcat 6.0 and caching of files. I'd really appreciate it if anyone could explain how caching could be disabled. >>> >>> Read the docs. I'd start with this: >>> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html >>> >>> Mark >>> >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >> >> > signature.asc Description: OpenPGP digital signature
Re: Tomcat 6.0.20 is running out of memory
On 21/05/2010 13:25, kent.anders...@tieto.com wrote: > Hi, > > This is what jmap -heap gives: > > using thread-local object allocation. > Mark Sweep Compact GC > > Heap Configuration: >MinHeapFreeRatio = 40 >MaxHeapFreeRatio = 70 >MaxHeapSize = 134217728 (128.0MB) >NewSize = 2228224 (2.125MB) >MaxNewSize = 4294901760 (4095.9375MB) >OldSize = 4194304 (4.0MB) >NewRatio = 8 >SurvivorRatio= 8 >PermSize = 12582912 (12.0MB) >MaxPermSize = 67108864 (64.0MB) > > Heap Usage: > New Generation (Eden + 1 Survivor Space): >capacity = 6160384 (5.875MB) >used = 1667072 (1.58984375MB) >free = 4493312 (4.28515625MB) >27.06117021276596% used > > Eden Space: >capacity = 5505024 (5.25MB) >used = 1667072 (1.58984375MB) >free = 3837952 (3.66015625MB) >30.282738095238095% used > From Space: >capacity = 655360 (0.625MB) >used = 0 (0.0MB) >free = 655360 (0.625MB) >0.0% used > To Space: >capacity = 655360 (0.625MB) >used = 0 (0.0MB) >free = 655360 (0.625MB) >0.0% used > tenured generation: >capacity = 54312960 (51.796875MB) >used = 32587664 (31.078018188476562MB) >free = 21725296 (20.718856811523438MB) >59.99979378770739% used > Perm Generation: >capacity = 12582912 (12.0MB) >used = 10470144 (9.985107421875MB) >free = 2112768 (2.014892578125MB) >83.209228515625% used Do you have the -Xms flag set to the same value as -Xmx? It's usually advised hereabouts to set them to the same value, so the JVM doesn't have to expend time increasing the heap size. If your app is experiencing more requests then you may need to allocate more memory to the heap. The amount you'll need is entirely specific to your application. Assuming you've got actual RAM spare, (if you haven't you'll use swap and your performance will suffer horribly), you can try increasing the amount by increments (of say 32Mb). p > -Original Message- > From: Pid [mailto:p...@pidster.com] > Sent: den 21 maj 2010 14:20 > To: Tomcat Users List > Subject: Re: Tomcat 6.0.20 is running out of memory > > On 21/05/2010 12:57, kent.anders...@tieto.com wrote: >> Hi, >> >> We are running Jakarta Tomcat Servlet/JSP Engine 6.0.20 on Solaris 2.10. >> We have -Xmx128M, is that to small? > > Maybe. :) > > What did the jmap -heap command produce? > > > p > > >> Best Regards >> /Kent >> >> -Original Message- >> From: Pid [mailto:p...@pidster.com] >> Sent: den 21 maj 2010 13:20 >> To: Tomcat Users List >> Subject: Re: Tomcat 6.0.20 is running out of memory >> >> On 21/05/2010 11:57, kent.anders...@tieto.com wrote: >>> Hi, >>> >>> The Tomcat webserver 6.0.20 we are using has run out of memory. >>> Got the following message in the Catalina.out file: >>> less /opt/jakarta/tomcat/logs/catalina.out >>> ... >>> java.lang.OutOfMemoryError: Java heap space >>> at java.util.Properties$LineReader.(Properties.java:389) >>> at java.util.Properties.load(Properties.java:325) >>> at java.util.PropertyResourceBundle. >>> (PropertyResourceBundle.java:111) >>> at >>> java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2428) >>> at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1406) >>> at java.util.ResourceBundle.findBundle(ResourceBundle.java:1365) >>> at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) >>> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) >>> at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) >>> at org.apache.jasper.compiler.Localizer.(Localizer.java:36) >>> at org.apache.jasper.runtime.PageContextImpl.release >>> (PageContextImpl.java:191) >>> at >>> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext >>> (JspFactoryImpl.java:118) >>> at >>> org.apache.jasper.runtime.JspFactoryImpl.releasePageContext >>> (JspFactoryImpl.java:77) >>> at org.apache.jsp.contents_jsp._jspService(contents_jsp.java:174) >>> at >>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >>> at org.apache.jasper.servlet.JspServletWrapper.service >>> (JspServletWrapper.java:374) >>> at org.apache.jasper.servlet.JspServlet.serviceJspFile >>> (JspServlet.java:342) >>> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter >>> (ApplicationFilterChain.java:290) >>> at org.apache.catalina.core.ApplicationFilterChain.doFilter >>> (ApplicationFilterChain.java:206) >>> at org.apache.catalina.core.ApplicationDispatcher.invoke >>> (ApplicationDispatcher.java:646
Re: disable caching of static files in tomcat 5.5
Ive got the same problem - did anyone figure out what is happening and why tomcat is caching files behind symlinks? Epithemeus wrote: > > Thanks Mark. > > I went through the documentation but the problem persists. I am using > Tomcat 6.0 and have tried including cachingAllowed="false" in > $CATALINA_HOME/conf/context.xml. This does not seem to work. > > There is no other context.xml file currently defined in directory > structure anywhere. Any ideas on why this still isn't working? > > Thanks. > > > Mark Thomas-18 wrote: >> >> Epithemeus wrote: >>> Hi Joerg, >>> >>> I am facing the same issue with Tomcat 6.0 and caching of files. I'd >>> really >>> appreciate it if anyone could explain how caching could be disabled. >> >> Read the docs. I'd start with this: >> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html >> >> Mark >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> > > -- View this message in context: http://old.nabble.com/disable-caching-of-static-files-in-tomcat-5.5-tp19509596p28634513.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 6.0.20 is running out of memory
Pid wrote: On 21/05/2010 12:57, kent.anders...@tieto.com wrote: Hi, We are running Jakarta Tomcat Servlet/JSP Engine 6.0.20 on Solaris 2.10. That may have been a 16-bit version. We have -Xmx128M, is that to small? in which case this would be no mean feat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.20 is running out of memory
Hi, This is what jmap -heap gives: using thread-local object allocation. Mark Sweep Compact GC Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 134217728 (128.0MB) NewSize = 2228224 (2.125MB) MaxNewSize = 4294901760 (4095.9375MB) OldSize = 4194304 (4.0MB) NewRatio = 8 SurvivorRatio= 8 PermSize = 12582912 (12.0MB) MaxPermSize = 67108864 (64.0MB) Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 6160384 (5.875MB) used = 1667072 (1.58984375MB) free = 4493312 (4.28515625MB) 27.06117021276596% used Eden Space: capacity = 5505024 (5.25MB) used = 1667072 (1.58984375MB) free = 3837952 (3.66015625MB) 30.282738095238095% used >From Space: capacity = 655360 (0.625MB) used = 0 (0.0MB) free = 655360 (0.625MB) 0.0% used To Space: capacity = 655360 (0.625MB) used = 0 (0.0MB) free = 655360 (0.625MB) 0.0% used tenured generation: capacity = 54312960 (51.796875MB) used = 32587664 (31.078018188476562MB) free = 21725296 (20.718856811523438MB) 59.99979378770739% used Perm Generation: capacity = 12582912 (12.0MB) used = 10470144 (9.985107421875MB) free = 2112768 (2.014892578125MB) 83.209228515625% used Best regards /Kent -Original Message- From: Pid [mailto:p...@pidster.com] Sent: den 21 maj 2010 14:20 To: Tomcat Users List Subject: Re: Tomcat 6.0.20 is running out of memory On 21/05/2010 12:57, kent.anders...@tieto.com wrote: > Hi, > > We are running Jakarta Tomcat Servlet/JSP Engine 6.0.20 on Solaris 2.10. > We have -Xmx128M, is that to small? Maybe. :) What did the jmap -heap command produce? p > Best Regards > /Kent > > -Original Message- > From: Pid [mailto:p...@pidster.com] > Sent: den 21 maj 2010 13:20 > To: Tomcat Users List > Subject: Re: Tomcat 6.0.20 is running out of memory > > On 21/05/2010 11:57, kent.anders...@tieto.com wrote: >> Hi, >> >> The Tomcat webserver 6.0.20 we are using has run out of memory. >> Got the following message in the Catalina.out file: >> less /opt/jakarta/tomcat/logs/catalina.out >> ... >> java.lang.OutOfMemoryError: Java heap space >> at java.util.Properties$LineReader.(Properties.java:389) >> at java.util.Properties.load(Properties.java:325) >> at java.util.PropertyResourceBundle. >> (PropertyResourceBundle.java:111) >> at >> java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2428) >> at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1406) >> at java.util.ResourceBundle.findBundle(ResourceBundle.java:1365) >> at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) >> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) >> at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) >> at org.apache.jasper.compiler.Localizer.(Localizer.java:36) >> at org.apache.jasper.runtime.PageContextImpl.release >> (PageContextImpl.java:191) >> at >> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext >> (JspFactoryImpl.java:118) >> at >> org.apache.jasper.runtime.JspFactoryImpl.releasePageContext >> (JspFactoryImpl.java:77) >> at org.apache.jsp.contents_jsp._jspService(contents_jsp.java:174) >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at org.apache.jasper.servlet.JspServletWrapper.service >> (JspServletWrapper.java:374) >> at org.apache.jasper.servlet.JspServlet.serviceJspFile >> (JspServlet.java:342) >> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter >> (ApplicationFilterChain.java:290) >> at org.apache.catalina.core.ApplicationFilterChain.doFilter >> (ApplicationFilterChain.java:206) >> at org.apache.catalina.core.ApplicationDispatcher.invoke >> (ApplicationDispatcher.java:646) >> at org.apache.catalina.core.ApplicationDispatcher.doInclude >> (ApplicationDispatcher.java:551) >> at org.apache.catalina.core.ApplicationDispatcher.include >> (ApplicationDispatcher.java:488) >> at org.apache.jasper.runtime.JspRuntimeLibrary.include >> (JspRuntimeLibrary.java:968) >> at org.apache.jsp.mainpage_jsp._jspService(mainpage_jsp.java:109) >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at org.apache.jasper.servlet.JspServletWrapper.service >> (JspServletWrapper.java:374) >> at org.apache.jasper.servlet.JspServlet.serviceJspFile >> (JspServlet.java:342) >> at >> org.apac
Re: [OT] Tomcat 6.0.20 is running out of memory
On 21/05/2010 12:37, André Warnier wrote: > Pid wrote: > ... > >> >> jmap -heap >> > Mmmm. Is the above the /real/ explanation of your so-called crystal > ball ? I've always been quite sceptical about it. But now we know the > trick. People, have you noticed ? He does that every time. That's how > he knows all that stuff. I am in your serverz, mappin' your heapz. p > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > signature.asc Description: OpenPGP digital signature
Re: Tomcat 6.0.20 is running out of memory
On 21/05/2010 12:57, kent.anders...@tieto.com wrote: > Hi, > > We are running Jakarta Tomcat Servlet/JSP Engine 6.0.20 on Solaris 2.10. > We have -Xmx128M, is that to small? Maybe. :) What did the jmap -heap command produce? p > Best Regards > /Kent > > -Original Message- > From: Pid [mailto:p...@pidster.com] > Sent: den 21 maj 2010 13:20 > To: Tomcat Users List > Subject: Re: Tomcat 6.0.20 is running out of memory > > On 21/05/2010 11:57, kent.anders...@tieto.com wrote: >> Hi, >> >> The Tomcat webserver 6.0.20 we are using has run out of memory. >> Got the following message in the Catalina.out file: >> less /opt/jakarta/tomcat/logs/catalina.out >> ... >> java.lang.OutOfMemoryError: Java heap space >> at java.util.Properties$LineReader.(Properties.java:389) >> at java.util.Properties.load(Properties.java:325) >> at java.util.PropertyResourceBundle. >> (PropertyResourceBundle.java:111) >> at >> java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2428) >> at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1406) >> at java.util.ResourceBundle.findBundle(ResourceBundle.java:1365) >> at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) >> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) >> at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) >> at org.apache.jasper.compiler.Localizer.(Localizer.java:36) >> at org.apache.jasper.runtime.PageContextImpl.release >> (PageContextImpl.java:191) >> at >> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext >> (JspFactoryImpl.java:118) >> at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext >> (JspFactoryImpl.java:77) >> at org.apache.jsp.contents_jsp._jspService(contents_jsp.java:174) >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at org.apache.jasper.servlet.JspServletWrapper.service >> (JspServletWrapper.java:374) >> at org.apache.jasper.servlet.JspServlet.serviceJspFile >> (JspServlet.java:342) >> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter >> (ApplicationFilterChain.java:290) >> at org.apache.catalina.core.ApplicationFilterChain.doFilter >> (ApplicationFilterChain.java:206) >> at org.apache.catalina.core.ApplicationDispatcher.invoke >> (ApplicationDispatcher.java:646) >> at org.apache.catalina.core.ApplicationDispatcher.doInclude >> (ApplicationDispatcher.java:551) >> at org.apache.catalina.core.ApplicationDispatcher.include >> (ApplicationDispatcher.java:488) >> at org.apache.jasper.runtime.JspRuntimeLibrary.include >> (JspRuntimeLibrary.java:968) >> at org.apache.jsp.mainpage_jsp._jspService(mainpage_jsp.java:109) >> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at org.apache.jasper.servlet.JspServletWrapper.service >> (JspServletWrapper.java:374) >> at org.apache.jasper.servlet.JspServlet.serviceJspFile >> (JspServlet.java:342) >> at >> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) >> ERROR: 'Java heap space' >> Does anyone have any idea how to prevent this, or why this is happening? > > Your application has used all the memory it has allocated, prevent the error > by allocating more memory, unless your application has a memory leak - in > which case, find the leak and fix it. > > You're on a linux variant presumably? Please state your exact JVM version, & > OS info. In this case the amount of hardware RAM available would be useful > too. > > Do you have any memory settings in your JAVA_OPTS or CATALINA_OPTS? > (If you're not sure, they look like "-Xmx1024M" for example.) > > Execute the following command to find out what the heap is using: > > jmap -heap > > > p > > > > > > > > > > signature.asc Description: OpenPGP digital signature
RE: Tomcat 6.0.20 is running out of memory
Hi, We are running Jakarta Tomcat Servlet/JSP Engine 6.0.20 on Solaris 2.10. We have -Xmx128M, is that to small? Best Regards /Kent -Original Message- From: Pid [mailto:p...@pidster.com] Sent: den 21 maj 2010 13:20 To: Tomcat Users List Subject: Re: Tomcat 6.0.20 is running out of memory On 21/05/2010 11:57, kent.anders...@tieto.com wrote: > Hi, > > The Tomcat webserver 6.0.20 we are using has run out of memory. > Got the following message in the Catalina.out file: > less /opt/jakarta/tomcat/logs/catalina.out > ... > java.lang.OutOfMemoryError: Java heap space > at java.util.Properties$LineReader.(Properties.java:389) > at java.util.Properties.load(Properties.java:325) > at java.util.PropertyResourceBundle. > (PropertyResourceBundle.java:111) > at > java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2428) > at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1406) > at java.util.ResourceBundle.findBundle(ResourceBundle.java:1365) > at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) > at org.apache.jasper.compiler.Localizer.(Localizer.java:36) > at org.apache.jasper.runtime.PageContextImpl.release > (PageContextImpl.java:191) > at > org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext > (JspFactoryImpl.java:118) > at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext > (JspFactoryImpl.java:77) > at org.apache.jsp.contents_jsp._jspService(contents_jsp.java:174) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at org.apache.jasper.servlet.JspServletWrapper.service > (JspServletWrapper.java:374) > at org.apache.jasper.servlet.JspServlet.serviceJspFile > (JspServlet.java:342) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter > (ApplicationFilterChain.java:290) > at org.apache.catalina.core.ApplicationFilterChain.doFilter > (ApplicationFilterChain.java:206) > at org.apache.catalina.core.ApplicationDispatcher.invoke > (ApplicationDispatcher.java:646) > at org.apache.catalina.core.ApplicationDispatcher.doInclude > (ApplicationDispatcher.java:551) > at org.apache.catalina.core.ApplicationDispatcher.include > (ApplicationDispatcher.java:488) > at org.apache.jasper.runtime.JspRuntimeLibrary.include > (JspRuntimeLibrary.java:968) > at org.apache.jsp.mainpage_jsp._jspService(mainpage_jsp.java:109) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at org.apache.jasper.servlet.JspServletWrapper.service > (JspServletWrapper.java:374) > at org.apache.jasper.servlet.JspServlet.serviceJspFile > (JspServlet.java:342) > at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > ERROR: 'Java heap space' > Does anyone have any idea how to prevent this, or why this is happening? Your application has used all the memory it has allocated, prevent the error by allocating more memory, unless your application has a memory leak - in which case, find the leak and fix it. You're on a linux variant presumably? Please state your exact JVM version, & OS info. In this case the amount of hardware RAM available would be useful too. Do you have any memory settings in your JAVA_OPTS or CATALINA_OPTS? (If you're not sure, they look like "-Xmx1024M" for example.) Execute the following command to find out what the heap is using: jmap -heap p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomat monitoring
On Fri, May 21, 2010 at 9:33 AM, wrote: > > Hi all, > > I work on JavaMelody and I can speak about the question of jconsole or > javamelody for Tomcat monitoring. > > The main differences between jconsole and javamelody is IMHO that jconsole > will > be used occasionally in QA or production for a few minutes or a few hours, > whereas javamelody will be always enabled in the application in QA or > production > with reports for current day, week, month or current year. agreed. ... > > Is JavaMelody used in production? Yes, some people said so in the users group: > http://groups.google.fr/group/javamelody or in private. > I use it myself for several applications, one of which costs 25 person years. Sorry, what does that mean? There are 25 person years invested in the development of the application? or in the development of javamelody. regards Leon > > Any problems? In general, JavaMelody is installed in 10 minutes for a good > developer (as JavaMelody is opensource and free, there is no budget to find). > And sometimes, some applications need a bit more configuration: > http://code.google.com/p/javamelody/wiki/UserGuide Yet another java monitoring framework ;-) > > Please note that the target of JavaMelody is not content portals such as > www.acikkod.org, but more on intranet applications using databases (+ hudson, > grails, jira and soon confluence and bamboo). > > bye, Emeric > ever...@free.fr > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat 6.0.20 is running out of memory
Pid wrote: ... jmap -heap Mmmm. Is the above the /real/ explanation of your so-called crystal ball ? I've always been quite sceptical about it. But now we know the trick. People, have you noticed ? He does that every time. That's how he knows all that stuff. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.20 is running out of memory
On 21/05/2010 11:57, kent.anders...@tieto.com wrote: > Hi, > > The Tomcat webserver 6.0.20 we are using has run out of memory. > Got the following message in the Catalina.out file: > less /opt/jakarta/tomcat/logs/catalina.out > ... > java.lang.OutOfMemoryError: Java heap space > at java.util.Properties$LineReader.(Properties.java:389) > at java.util.Properties.load(Properties.java:325) > at java.util.PropertyResourceBundle. > (PropertyResourceBundle.java:111) > at > java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2428) > at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1406) > at java.util.ResourceBundle.findBundle(ResourceBundle.java:1365) > at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) > at org.apache.jasper.compiler.Localizer.(Localizer.java:36) > at org.apache.jasper.runtime.PageContextImpl.release > (PageContextImpl.java:191) > at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext > (JspFactoryImpl.java:118) > at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext > (JspFactoryImpl.java:77) > at org.apache.jsp.contents_jsp._jspService(contents_jsp.java:174) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at org.apache.jasper.servlet.JspServletWrapper.service > (JspServletWrapper.java:374) > at org.apache.jasper.servlet.JspServlet.serviceJspFile > (JspServlet.java:342) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter > (ApplicationFilterChain.java:290) > at org.apache.catalina.core.ApplicationFilterChain.doFilter > (ApplicationFilterChain.java:206) > at org.apache.catalina.core.ApplicationDispatcher.invoke > (ApplicationDispatcher.java:646) > at org.apache.catalina.core.ApplicationDispatcher.doInclude > (ApplicationDispatcher.java:551) > at org.apache.catalina.core.ApplicationDispatcher.include > (ApplicationDispatcher.java:488) > at org.apache.jasper.runtime.JspRuntimeLibrary.include > (JspRuntimeLibrary.java:968) > at org.apache.jsp.mainpage_jsp._jspService(mainpage_jsp.java:109) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at org.apache.jasper.servlet.JspServletWrapper.service > (JspServletWrapper.java:374) > at org.apache.jasper.servlet.JspServlet.serviceJspFile > (JspServlet.java:342) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > ERROR: 'Java heap space' > Does anyone have any idea how to prevent this, or why this is happening? Your application has used all the memory it has allocated, prevent the error by allocating more memory, unless your application has a memory leak - in which case, find the leak and fix it. You're on a linux variant presumably? Please state your exact JVM version, & OS info. In this case the amount of hardware RAM available would be useful too. Do you have any memory settings in your JAVA_OPTS or CATALINA_OPTS? (If you're not sure, they look like "-Xmx1024M" for example.) Execute the following command to find out what the heap is using: jmap -heap p signature.asc Description: OpenPGP digital signature
Tomcat 6.0.20 is running out of memory
Hi, The Tomcat webserver 6.0.20 we are using has run out of memory. Got the following message in the Catalina.out file: less /opt/jakarta/tomcat/logs/catalina.out ... java.lang.OutOfMemoryError: Java heap space at java.util.Properties$LineReader.(Properties.java:389) at java.util.Properties.load(Properties.java:325) at java.util.PropertyResourceBundle. (PropertyResourceBundle.java:111) at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2428) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1406) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1365) at java.util.ResourceBundle.findBundle(ResourceBundle.java:1292) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1234) at java.util.ResourceBundle.getBundle(ResourceBundle.java:715) at org.apache.jasper.compiler.Localizer.(Localizer.java:36) at org.apache.jasper.runtime.PageContextImpl.release (PageContextImpl.java:191) at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext (JspFactoryImpl.java:118) at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext (JspFactoryImpl.java:77) at org.apache.jsp.contents_jsp._jspService(contents_jsp.java:174) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:488) at org.apache.jasper.runtime.JspRuntimeLibrary.include (JspRuntimeLibrary.java:968) at org.apache.jsp.mainpage_jsp._jspService(mainpage_jsp.java:109) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:374) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) ERROR: 'Java heap space' Does anyone have any idea how to prevent this, or why this is happening? Best Regards /Kent
Re: user cancels download attachment
On 21/05/2010 03:08, Ðavîd Låndïs wrote: > On Thu, May 20, 2010 at 9:51 PM, Caldarale, Charles R > wrote: >>> From: Ðavîd Låndïs [mailto:dlan...@gmail.com] >>> Subject: Re: user cancels download attachment >>> >>> I will try to debug deeper down into the platform. >> >> What connector are you using? Blocking, NIO, or APR? > > Blocking. > >> >>> I suppose it is possible there is something else >>> buffering it, but I don't think it is a proxy in >>> my case. Could it be Tomcat itself maybe? >> >> Tomcat does some buffering, but it obviously can't buffer too much, or the >> heap would be easily exhausted by any large request. I >haven't chased the >> code, but I would have to think that an explicit flush() call would push it >> out (and your experience seems to i>ndicate that's the case). > > OK I'll investigate a little more at work tomorrow. I'm hoping the > issue isn't that Tomcat is swallowing the exceptions somewhere. > > Incidentally, does anyone know what exception is supposed to be thrown > when a user cancels the attachment download? Write the bytes to a ServletOutputStream and you should see an exception if the client breaks the connection. p > Thanks Chuck. > > >> >> - 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 > signature.asc Description: OpenPGP digital signature
Re: Tomat monitoring
Hi all, I work on JavaMelody and I can speak about the question of jconsole or javamelody for Tomcat monitoring. The main differences between jconsole and javamelody is IMHO that jconsole will be used occasionally in QA or production for a few minutes or a few hours, whereas javamelody will be always enabled in the application in QA or production with reports for current day, week, month or current year. So jconsole will be used generally in order to have very fine details on heap, cpu or the java.util.logging MBeans, whereas javamelody will give global trends with graphics on heap, cpu, number of http sessions or http and sql mean response times. Most javamelody users are surprised by the data available in reports such as statistics on http requests, sql requests, ejb/spring/guice executions, jsp pages, quartz jobs or such as heap histogram, long requests in oracle sga... Reports are available in English or in French. Is JavaMelody used in production? Yes, some people said so in the users group: http://groups.google.fr/group/javamelody or in private. I use it myself for several applications, one of which costs 25 person years. Any problems? In general, JavaMelody is installed in 10 minutes for a good developer (as JavaMelody is opensource and free, there is no budget to find). And sometimes, some applications need a bit more configuration: http://code.google.com/p/javamelody/wiki/UserGuide Please note that the target of JavaMelody is not content portals such as www.acikkod.org, but more on intranet applications using databases (+ hudson, grails, jira and soon confluence and bamboo). bye, Emeric ever...@free.fr Le 20/05/2010, Ozgur Ozdemircili a écrit : > Are we loosing > > the subject here a bit? While mentioning the "monitoring" I > > refer to JVM monitoring. Heap usage etc. not the snmp monitoring. > > > > > Özgür Özdemircili > > http://www.acikkod.org > > Code so clean you could eat off it - Fin du message transféré - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: user cancels download attachment
Ðavîd Låndïs wrote: ... Incidentally, does anyone know what exception is supposed to be thrown when a user cancels the attachment download? I am bit out of my depth here, but presumably when the user does that, the browser closes its (reading) side of the socket. Whatever process is at the other end writing to it should then get a "attempt to write to a closed socket" kind of exception. But if there is anything in-between, which does not really reflect the condition up the chain, then it might be something else.. I mean if for instance there was a firewall, or a load-balancer, or an Apache http + mod_jk (which I know you all don't have right now, but may have in the future), then what you'd get at the Tomcat level is whatever results from the socket Tomcat is really writing to, not necessarily the browser directly. I seem to remember a discussion 3-4 months ago on this forum about a topic just like this one, ending finally in the consensus that it is the JVM itself which does not really make available to the Java application all the innards of the underlying OS-level socket. It may do that for potability reasons, or maybe because the JVM developers thought that Java programmers should not be concerned by such low-level considerations. Maybe Chuck remembers the topic of that thread, as I am sure he was part of it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
