Re: Regarding Connector in tomcat 6
Cummins College wrote: Hi, I know the problem is slightly different but we want to access the server.xml for the http connector so that we can set its secure attribute depending on the protocol to be used is http or https. This has to done at runtime i.e without shutting down tomcat and re-starting it. Is it possible to access the http connector at runtime and change its attributes? I believe that what people here do not understand, is *why* you would need to do that. It does not seem to make a lot of sense, on the face of it, and maybe there is another much simpler way to achieve what you really want to achieve. So can you tell us which would be *the purpose* of changing the characteristics of the Connector on-the-fly ? Let me give you an example, to explain why it is difficult for us to grasp your need : - suppose a browser starts a session with your server, with a URL like http://yourserver.yourcompany.com; - it gets a page back from the server. This page contains links to further pages on your site, like a href=/anotherpage.htmldocumentation/a - when clicking on that link, the browser is going to interpret this as the full URL : http://yourserver.yourcompany.com/anotherpage.html; - but if in the meantime, you would have changed the port 80 Connector to require HTTPS (assuming this is even possible, which I don't think it is), the browser would get an error, because it is still trying HTTP, as the link says. That kind of thing is what does not seem to make sense. It is not because you would be changing the Connector on the server side, that all pages which you have already sent to browsers are magically, through some action-at-a-distance, going to change their links. (or if you manage to do that, then tell us how, because that would be a real breakthrough) On the other hand, you can have two Connectors for the same website, one for HTTP and one for HTTPS, active at the same time, on different ports. Switching the client to use the one or the other is then just done by returning to the client different html documents, containing links to the port (and protocol) you want them to use next. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding Connector in tomcat 6
On 22/02/2010 07:28, Cummins College wrote: Hi, I know the problem is slightly different but we want to access the server.xml for the http connector so that we can set its secure attribute depending on the protocol to be used is http or https. You are confused. Changing the secure attribute wouldn't achieve what you want, because you need an entirely separate connector for each of HTTP and HTTPS. HTTPS, for example, runs on a different port (443 by default, rather than 80 for HTTP) and requires extra configuration to define the SSL protocol factors. This has to done at runtime i.e without shutting down tomcat and re-starting it. Why? Is it possible to access the http connector at runtime and change its attributes? Not without shutting down or restarting Tomcat. As others are asking, can you please explain what it is that you're trying to achieve and also why you think that your proposed solution will do that? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Client certificate gone after 1 minute timeout (SSL, APR)
Dear colleagues,
I'm chasing a strange problem with Tomcat + SSL + APR + Firefox.
Namely, the setup works perfectly (i.e. the client certificate is sent
and the servlet application can get it).
But if I allow the SSL connection to time out (it happens 1 minute
after the last request), the servlet application does not get the
client certificate anymore.
The workaround is to clear Firefox cache (Tools - Clear Recent History
- 1 hour, Active logins).
After this, the application will work again until the next timeout.
This problem does NOT occur if I use pure Java SSL config (no APR) or
when I use browser other that Firefox.
From that you can imply that this might be a Firefox problem, but I'm
not so sure.
Firefox works perfectly with all other HTTPS sites and also pure Java
SSL config works with Firefox.
So obviously this problem occurs because Tomcat libnative fails to
handle some peculiarities of Firefox SSL packets.
Here is my exact setup:
- Debian 5 (Lenny)
- libapr1 1.2.12-5+lenny1
- openssl 0.9.8g-15+lenny6
- Tomcat 6.0.24 with tomcat-native-1.1.19
- server authentication certificates (newcert.pem, newkey-no-password.pem)
- client authentication certificates (cas.crt and a personal
certificate signed by that)
- a simple servlet ssltest to get the client cert:
writer.println(Arrays.deepToString((X509Certificate[])
request.getAttribute(javax.servlet.request.X509Certificate)));
- Firefox 3.6
The only change in server.xml is the connector conf:
Connector port=8443 SSLEnabled=true
maxThreads=150 scheme=https secure=true
SSLCertificateFile=${user.home}/newcert.pem
SSLCertificateKeyFile=${user.home}/newkey-no-password.pem
SSLVerifyClient=require
SSLVerifyDepth=2
SSLCACertificateFile=${user.home}/cas.crt
/
Now steps to reproduce:
1) go to https://localhost:8443/ssltest, it will show the client certificate
2) wait 1 minute
3) refresh browser - the application will not get the client certificate
(request.getAttribute(javax.servlet.request.X509Certificate) returns null)
I have traced the SSL packets using ssltap -sxlp 8444 localhost:8443
It shows that 1 minute after the last request, there will be Read EOF
on Server socket.
After that, the problem starts occuring.
I have compared ssltap traces for Firefox and Safari.
They look pretty similar.
The only significant difference is that Safari seems to terminate the
connection by sending SSL alert packet.
In case of Firefox, it is the Tomcat server who sends the first SSL
alert packet.
I hope somebody can shed a light on that issue :)
Best Regards,
Albert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
sendRedirect problem
Hi I have a faces (JSF) app developed with JDeveloper, in a JSP i have a sendRedirect like this: response.sendRedirect(xxx.jsp); The problem: sendRedirect not working (the page where the redirect is invoked continues loading), occurs only when the app is deployed to Apache Tomcat. On the JDeveloper built-in debugger the code works fine: xxx.jsp appears. Any idea? Desbaratizador -- View this message in context: http://old.nabble.com/sendRedirect-problem-tp27686610p27686610.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
Tomcat 6.0.20 Returning NullPointer upon closing response.getWriter()
Tomcat returned NullpointerException upon closing response.getWriter(). This does not occur always but sometimes. Not able to figure out the reason. java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:740) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434) at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:390) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:987) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:276) at org.apache.catalina.connector.CoyoteWriter.close(CoyoteWriter.java:108) at com.onmobile.platform.sovxml.ControlServlet.doGet(ControlServlet.java:3482) -- #response.getWriter().close() at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) 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.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:361) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -- View this message in context: http://old.nabble.com/Tomcat-6.0.20-Returning-NullPointer-upon-closing-response.getWriter%28%29-tp27687328p27687328.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: Restart one webapp
Restarting works fine. I think the restarting mechanism is built into tomcat and not into the webapp itself. Konstantin: Thanks for the tip on wget documentation. I was reading tomcat docs only. jonsoons -Original Message- From: Mikolaj Rydzewski [mailto:m...@ceti.pl] Sent: Sunday, February 21, 2010 4:15 PM To: Tomcat Users List Subject: Re: Restart one webapp Jonathan Soons wrote: I have one webapp that randomly freezes. I detect this with a script and restart tomcat. I would prefer to restart just the one webapp the way the manager does. Are you soure, that manager is able to restart webapp when it is 'frozen'? -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding Connector in tomcat 6
From: Cummins College [mailto:cummins.grou...@gmail.com] Subject: Re: Regarding Connector in tomcat 6 But i would like to toggle entire web application to http or https at runtime. Then simply add or remove the transport-guarantee of CONFIDENTIAL; Tomcat will recognize that the webapp's WEB-INF/web.xml has changed and restart the app in the new mode. You still haven't made any sense about why you think this is a useful thing to do. - 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: Tomcat shutdown issue
Can you please suggest how to scan the port and check the port is used by other application. I am using socket programming to check the port this is right? awarnier wrote: As I believe someone already told you, there is no need to repeat every message twice. dBenjamin wrote: Tomcat not getting shutdown.. it shows the WARNING: StandardServer.await: Invalid command '' received can you pls find server.xml when I click shutdwon.bat server not listning it shows WARNING: StandardServer.await: Invalid command '' received can you please help me to solve this issues.. Also, you were already given the answer before : Probably (but we cannot tell that for sure just by your server.xml file), it looks like /something/ is sending a normal HTTP request (*) /to the shutdown port of the server/, instead of the normal HTTP port. Find which client is sending a HTTP request to his port : Server port=3006 shutdown=SHUTDOWN instead of this port : Connector connectionTimeout=3 port=6876 protocol=HTTP/1.1 redirectPort=8757/ and you will find the reason. (*) as a matter of fact, as per the logfile, it looks like this client is making a connection to port 3006 and then just sending an empty request. If you have software doing some kind of port scanning, that may be the culprit. - 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/RE%3A-WARNING%3A-StandardServer.await%3A-Invalid-command-%27%27-received-tp27652985p27691253.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
Webapp slow down after idle - 5.5.x
Hello, My webservice (using axis 1.1)is deployed on tomcat 5.5.28. Tomcat runs on AIX and IBM Java 1.5 SR9. The problem is that every first request after a longer idle (like a day) is served very slow. There's no performance problem with next requests. It looks quite similar to first request after tomcat restart yet there's no restart here. It's very difficult to spot the problem since most of the time everything runs fine and I have like one chance a day to test some new options. Any ideas about that ? Thanks in advance, Kate -- Kup wlasne mieszkanie za 72 tys. zl. Sprawdz najlepsze oferty http://link.interia.pl/f25a8 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp slow down after idle - 5.5.x
One thing that comes to mind is virtual memory swapping. If Tomcat is idle for a long time, all of its memory may be swapped out to disk to make room for other programs. Then when Tomcat needs to handle a request, it must be swapped back in from disk which takes time. I've observed the hard disk light flickering when this happens but I don't know if you want to spend the night camping in the server room watching for this. -- Len On 2010-02-22, at 13:29, klin...@poczta.fm wrote: Hello, My webservice (using axis 1.1)is deployed on tomcat 5.5.28. Tomcat runs on AIX and IBM Java 1.5 SR9. The problem is that every first request after a longer idle (like a day) is served very slow. There's no performance problem with next requests. It looks quite similar to first request after tomcat restart yet there's no restart here. It's very difficult to spot the problem since most of the time everything runs fine and I have like one chance a day to test some new options. Any ideas about that ? Thanks in advance, Kate -- Kup wlasne mieszkanie za 72 tys. zl. Sprawdz najlepsze oferty http://link.interia.pl/f25a8 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Webapp slow down after idle - 5.5.x
From: klin...@poczta.fm [mailto:klin...@poczta.fm] Subject: Webapp slow down after idle - 5.5.x The problem is that every first request after a longer idle (like a day) is served very slow. Sounds like the OS might be paging out Tomcat, and taking a long time to get all the necessary pages back in when a request is made. I'm not familiar with operational details of AIX, but I would suspect there are some system-level monitoring tools available to see if there is a paging spike in this situation. - 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: Webapp slow down after idle - 5.5.x
On 22 February 2010 19:07, Caldarale, Charles R chuck.caldar...@unisys.com wrote: Sounds like the OS might be paging out Tomcat, and taking a long time to get all the necessary pages back in when a request is made. I'm not familiar with operational details of AIX, but I would suspect there are some system-level monitoring tools available to see if there is a paging spike in this situation. vmstat (http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds6/vmstat.htm) would do the job. No finesse, but sufficient information :-). - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown issue
dBenjamin wrote: Can you please suggest how to scan the port and check the port is used by other application. On what kind of system are you ? Anyway, shut down Tomcat, then use the netstat command. Depending on the system on which you are, there are options to this command. Choose one that will show you either the process-id, or the name of the program which owns the sockets. Look for ports (on the local side) which have LISTEN around the end of the line. That should tell you the programs, apart from Tomcat, which are listening on various ports. Then turn on Tomcat, and enter the same command again. The differences between the first and second result should tell you which port Tomcat is listening on. I am using socket programming to check the port this is right? I do not understand this question. Explain what you are trying to do. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 on solaris losing cookies
Thanks for everyone's help... it was indeed app code.. some old ugly legacy
code was putting a reference to a request in a thread local variable and then
not cleaning up the thread local reference when the request ended. When the
thread was reused, it was referencing a request that was no longer valid (been
recycled) and all things went downhill from there.
We're still a bit confused as to why this code works fine in Tomcat 5.5 and
fails so gloriously in 6, but I suppose the recycling model and maybe the
thread handling model is different.
Thanks again!
-g.
On Feb 18, 2010, at 1:30 PM, George Baxter wrote:
Hmm, well it's possible. However, I'm not entirely confident that each
request has its own Cookies object. There is a 'setHeaders()' method on
Cookies. What's it for? Checking myself. Will add more logging as you
suggested.
We are using Spring MVC which uses ThreadLocal to store requests... and these
threads CAN spawn off child threads which 'inherit' the threadlocal
variables. I'm not sure this is happening particularly often for us, but
I'll be looking at that more closely.
-g.
On Feb 18, 2010, at 12:42 PM, Mark Thomas wrote:
On 18/02/2010 20:23, George Baxter wrote:
So we think we've found a threading problem in the cookie handling.
Hmm. Each request has its own Cookies object. The only way these would
be shared between threads is if two threads were using the same request
object. That usually happens when custom filters/valves wrap requests
and mix up the request/response objects. Putting requests and responses
into the session is another sign of things going awry.
I'd add some logging to check which request and cookies objects are
being used and see if you can track down where they are getting mixed
up. My money is on application code.
Mark
Running on Solaris 10, jdk 1.5, tomcat 6.0.24.
We built our 'own' version of 6.0.24, adding logging in some places, and
ultimately, this is what we discovered:
A bit of information: in these log entries, we're looking at 2 threads :
66 and 228.
We're also looking at 2 Cookies entities : 2021596579 and 1706042601.
Here's the modified 'getCookieCount()' method in Cookies:
public int getCookieCount() {
log(processed = + !unprocessed);
if( unprocessed ) {
unprocessed=false;
log(calling process cookies);
processCookies(headers);
}
return cookieCount;
}
First, thread 66 receives a request (from a monitoring process, has no
cookies):
Feb 18, 2010 11:31:04 AM org.apache.catalina.connector.CoyoteAdapter
parseSessionCookiesId
INFO: 66-parseSessionCookie for request: R( /)
Next, it's checking its cookie count, and here's something wrong already :
the unprocessed flag in Cookies is already set to false.. for Cookies
1706042601.
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 66,1706042601-C:processed = true
Next, we jump to thread 228: it seems to be busy ending a request using
Cookies 2021596579
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 228,2021596579-C:recycling Cookies
Back to thread 66, who suddenly seems to be using THE SAME COOKIES OBJECT:
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 66,2021596579-C:processed = false
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 66,2021596579-C:calling process cookies
Then, its now recycling Cookies.. in fact, it's recycling Cookies
1706042601 twice!
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 66,1706042601-C:recycling Cookies
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 66,1706042601-C:recycling Cookies
Back to 228, which is going to try to handle a new request. Note that at
this time, 2021596579 has not yet been recycled:
Feb 18, 2010 11:31:04 AM org.apache.catalina.connector.CoyoteAdapter
parseSessionCookiesId
INFO: 228-parseSessionCookie for request: R( /nav/mysfly.sfly)
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 228,2021596579-C:processed = true
Feb 18, 2010 11:31:04 AM org.apache.tomcat.util.http.Cookies log
INFO: 228,2021596579-C:recycling Cookies
And thus, we've lost our session reference.
God I hope the formatting holds when I send this
-George
On Feb 17, 2010, at 12:00 PM, George Baxter wrote:
Downloaded src code of tomcat for debugging purposes and sure enough, our
cookies are of type byte, so the fact that the code can parse the cookie
'string' just fine means diddly-squat.
Next plan, build my own tomcat 6.0.24 version with lots of logging and
checks for debugging purposes...
-g.
On Feb 16, 2010, at 4:22 PM, George Baxter wrote:
Well.. we parsed the header that failed, and it parsed just fine.
Note that we're parsing via the 'old deprecated' parse by string entity. I
guess I'll try parsing
Re: tomcat 6 on solaris losing cookies
George Baxter wrote: ... We're still a bit confused as to why this code works fine in Tomcat 5.5 and fails so gloriously in 6, but I suppose the recycling model and maybe the thread handling model is different. Yeah, that's always the problem when correcting bugs in released software. A lot of applications which relied on it being there, start to fail. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.20 Returning NullPointer upon closing response.getWriter()
Hi, have you checked, that you aren't sharing the request object by saving it in an instance variable? Sharing it would explain such an error. Bye Felix chinmaytotekar chinmaytote...@gmail.com schrieb: Tomcat returned NullpointerException upon closing response.getWriter(). This does not occur always but sometimes. Not able to figure out the reason. java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:740) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434) at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:390) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:987) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:276) at org.apache.catalina.connector.CoyoteWriter.close(CoyoteWriter.java:108) at com.onmobile.platform.sovxml.ControlServlet.doGet(ControlServlet.java:3482) -- #response.getWriter().close() at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) 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.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:361) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -- View this message in context: http://old.nabble.com/Tomcat-6.0.20-Returning-NullPointer-upon-closing-response.getWriter%28%29-tp27687328p27687328.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: sendRedirect problem
On 22/02/2010 12:39, Desbaratizador wrote: Hi I have a faces (JSF) app developed with JDeveloper, in a JSP i have a sendRedirect like this: response.sendRedirect(xxx.jsp); Does xxx stand for something and if so, what? (Don't tell us if the actual page name is something exciting and proprietory, who knows what we might do with that knowledge.) The problem: sendRedirect not working (the page where the redirect is invoked continues loading), occurs only when the app is deployed to Apache Tomcat. On the JDeveloper built-in debugger the code works fine: xxx.jsp appears. So it works on the server, it works in the debugger. When doesn't it work? Any idea? From the almost none-existent information you've provided, no, not really. Exact Tomcat, JVM, OS versions and *lot* more specific information would be useful. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: sendRedirect problem
If I had to guess, there is a missing FacesContext.responseComplete(); Prior to the sendRedirect call. DJ On 2/22/10, Pid p...@pidster.com wrote: On 22/02/2010 12:39, Desbaratizador wrote: Hi I have a faces (JSF) app developed with JDeveloper, in a JSP i have a sendRedirect like this: response.sendRedirect(xxx.jsp); Does xxx stand for something and if so, what? (Don't tell us if the actual page name is something exciting and proprietory, who knows what we might do with that knowledge.) The problem: sendRedirect not working (the page where the redirect is invoked continues loading), occurs only when the app is deployed to Apache Tomcat. On the JDeveloper built-in debugger the code works fine: xxx.jsp appears. So it works on the server, it works in the debugger. When doesn't it work? Any idea? From the almost none-existent information you've provided, no, not really. Exact Tomcat, JVM, OS versions and *lot* more specific information would be useful. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is it possible to replace the HttpSession implementation in Tomcat?
Just in case somebody will google for a solution for replacing session. I have done this . First of all ,why: We have cluster of 2 machines . Each have a separate db on it . The machines are sharing information using nfs mounting fs. Each machine runs it's own apache server ,(no apache balancer in front). There IS a hardware load balancer in front of this but sometime it fails to route already open sessions to same host. So,we can't : 1. share sessions using files ,because this would be same file for 2 tomcats and because this would fail on nfs . 2. we can't use tomcat cluster because there are cases when BOTH tomcat would be shut down or restarted and session would be loosed. 3. we can't use a db because there is no central db - each host has it's own one. 4. to complicate issue machines could be added/removed to the cluster. What we did - override session object using filter.On each request start it would read it's info from db (any configured one ,but preferring the local one) On each request end it would write itself into ALL dbs that are configured to be used. Although the obvious problem here is the writing to more then 1 db and reading from a db on each request ,this really works good thanks for mysql to be so fast on simple read/write. I have even implemented a simple lock mechanism for session . What more - this solution is portable ,it worked for us on SunONE server and now on tomcat. Thanks Evgeny On Tue, Feb 16, 2010 at 9:54 PM, Simone Tripodi simone.trip...@gmail.comwrote: Hi Martin, very interesting, thanks for share it!!! I did, more or less, the same on a project for a customer, but it was strictly related to the application, your stuff looks much much better of mine and it is a reusable module. All the best, Simo http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ On Tue, Feb 16, 2010 at 6:02 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi Jon, On Mon, 2010-02-15 at 11:55 -0600, Jon Brisbin wrote: I'm trying to figure out today how I can implement a Valve or something that can store a session to a backend DB and reload that session on another Tomcat instance similar to how the PersistentManager loads user's session after a restart. Would a Valve based on PersistentValve allow me to implement a cluster-like solution such that a user login causes a write to a central database and a load balanced request to another server would see that user without forcing another login? You might have a look at the http://code.google.com/p/memcached-session-manager/ which is a session failover solution storing sessions in memcached. When the project was created I only thought of applications using sticky sessions but it should also work with non-sticky sessions if sessions are stored in memcached synchronously (sessionBackupAsync needs to be set to false, see [1]). The memcached-session-manager basically is a session manager implemention, the most interesting part is the MemcachedBackupSessionManager ([2]) if you want to have a look at the code. Cheers, Martin [1] http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration [2] http://github.com/magro/memcached-session-manager/blob/master/core/src/main/java/de/javakaffee/web/msm/MemcachedBackupSessionManager.java Jon Brisbin Portal Webmaster NPC International, Inc. On Feb 15, 2010, at 11:05 AM, Simone Tripodi wrote: Hi all guys and very nice to meet the Tomcat community, I've a web-application that needs to be replicated in more than one Tomcat, and since it is HttpSession based, I need to enable the session replication. Even if I work with very good sysadmins that know how to do it, I'm curious and would like to know if I could replace the HttpSession implementation with a my own one, I'd like to integrate Hazelcast[1] for data synchronization. Thanks in advance, every suggestion will be very appreciated. Simo [1] http://www.hazelcast.com/ http://people.apache.org/~simonetripodi/http://people.apache.org/%7Esimonetripodi/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.20 Returning NullPointer upon closing response.getWriter()
Thanks The problem was response.getWriter() object was declared as global in servlet, so it became common to all threads. and if one thread closes it, it used to give NullPtrException in other threads. Felix Schumacher wrote: Hi, have you checked, that you aren't sharing the request object by saving it in an instance variable? Sharing it would explain such an error. Bye Felix chinmaytotekar chinmaytote...@gmail.com schrieb: Tomcat returned NullpointerException upon closing response.getWriter(). This does not occur always but sometimes. Not able to figure out the reason. java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:740) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434) at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:390) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:987) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:276) at org.apache.catalina.connector.CoyoteWriter.close(CoyoteWriter.java:108) at com.onmobile.platform.sovxml.ControlServlet.doGet(ControlServlet.java:3482) -- #response.getWriter().close() at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) 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.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:361) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -- View this message in context: http://old.nabble.com/Tomcat-6.0.20-Returning-NullPointer-upon-closing-response.getWriter%28%29-tp27687328p27687328.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 - 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/Tomcat-6.0.20-Returning-NullPointer-upon-closing-response.getWriter%28%29-tp27687328p27699412.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: Calling flushBuffer() in TOMCAT 6.0.20 returning NullPointerException.
Ya got the problem.. The problem was response.getWriter() object was declared as global in servlet, so it became common to all threads. and if one thread closes it, it used to give NullPtrException in other threads. Konstantin Kolinko wrote: 2010/2/19 Christopher Schultz ch...@christopherschultz.net: Konstantin, On 2/19/2010 2:22 PM, Konstantin Kolinko wrote: 1. The OP (chinmaytotekar) never mentioned what Tomcat version (s)he was using. What a disgrace. The thread subject seems to contradict this statement. Ah, sorry. I missed that. Best regards, Konstantin Kolinko - 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/Calling-flushBuffer%28%29-in-TOMCAT-6.0.20-returning-NullPointerException.-tp27652584p27699460.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
