Re: Did anyone had problems with JspWriter in Tomcat 5.5.17?
Hello, Borut. Are you sure that there are no other thread writing in the cache at this moment? How do you prevent this case? Best regards. Ricardo Borut Hadžialić escribió: Hi list, I have spent last 15 working hours trying to figure out the cause of a strange bug. Home page on one of our web sites sometimes gets generated with no content - as a blank page, the response buffer having size 0. We use caching filter (modified CachingFilter from Ehcache 1.3.0) which uses a response wrapper to capture responses to make caching possible. The response wrapper internaly uses standard classes ByteArrayOutputStream and PrintWriter from the Java API. The page cache time-to-live is set to 1 day. When the page is generated first time by jsps and tiles it is put into cache, and served for next 24 hours from the cache. After 24 hours it gets generated again. The manifestation of the bug is that randomly, the homepage gets generated as a blank page, about once in every 3 cache refreshes. When it occurs, the ByteArrayOutputStream has size 0, after the generation of the page has completed. Generating the homepage involves pulling some data from the database, which changes rarely, about once every week. I put cache time to live 300 seconds to eliminate the posibility that corrupt data from database causes errors in page generation. With 300 second time to live the problem was still there. The data in database does not change between good and faulty page generations. Home page is relatively simple - it does not involve pulling data from other data sources. It just reads some data the database and uses that data to make some html, using jsp. After turning on logging on database calls, all filters, and using a PrintWriter decorator inside our response wraper that echoes all print statements to the log, I found out something strange - A correct page generation logs some database calls (by the database logger), then a chunk of html (by the logging PrintWriter decorator, as a result of flushing JspWriter after enough out.write calls have been made), then some more database calls, then some more html.. and the page gets generated. ** A faulty generation (the one that produces a blank page) logs exactly same database calls as a correct page generation, but the log entries produced by the echoing PrintWriter are missing! **, like as jsps are executing normally, but something is wrong with the JspWriter out object. I am suspecting that somehow JspWriter writes somewhere else, not where it should. It should write into response wrapper's buffer, though the echoing/logging PrintWriter. But there is no PrintWriter echo and no bytes in response wrapper buffer... more exactly, *sometimes* there is no PrintWriter echo and no bytes in response wrapper buffer. I have read all the code that makes up the life cycle of PageContext and JspWriter on the docjar site (not sure for what version of Tomcat), and couldn't find anything that would help me solve this. http://www.docjar.com/html/api/org/apache/jasper/runtime/JspWriterImpl.java.html http://www.docjar.com/html/api/org/apache/jasper/runtime/PageContextImpl.java.html http://www.docjar.com/html/api/org/apache/jasper/runtime/JspFactoryImpl.java.html After adding some more logging statements I found out that 1 instance of JspWritter and 1 instance of PageContext are used shared across all page generations (site has low traffic and rarely 2 requests in same time). Same JspWritter and PageContext instances sometimes participate in good page and faulty page generations. I was hoping that someone on this list might know something that could help me find out why is this happening. Please help. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Did anyone had problems with JspWriter in Tomcat 5.5.17?
Hi Borut. I don't know the ehcache framework. What is the method used to prevent the thread collision? If I had this error, would try to make the most simple example to reproduce it. A simple wrapper and singleton class could be a good beginnin. Then grow the example until the error reproduces. Best regards. Ricardo Borut Hadžialić escribió: The caching filter uses a BlockingCache. A miss (get that returns null) locks that entry/key, and other threads that try to get the page from the cache using the same key, must wait until the thread that locked the entry puts something into the cache and releases the lock. Lock are released implicitly when cache put method is called, by the thread that locked it. All this is implemented inside Ehcache. We havent observed any thread deadlock problems (using JMX to monitor servers) Lock implementation is net.sf.ehcache.constructs.concurrent.Mutex which is a copy of Doug Lea's mutex class from standard Java API, copied and imported into Ehcache. On 7/16/07, rpr_listas [EMAIL PROTECTED] wrote: Hello, Borut. Are you sure that there are no other thread writing in the cache at this moment? How do you prevent this case? Best regards. Ricardo Borut Hadžialić escribió: Hi list, I have spent last 15 working hours trying to figure out the cause of a strange bug. Home page on one of our web sites sometimes gets generated with no content - as a blank page, the response buffer having size 0. We use caching filter (modified CachingFilter from Ehcache 1.3.0) which uses a response wrapper to capture responses to make caching possible. The response wrapper internaly uses standard classes ByteArrayOutputStream and PrintWriter from the Java API. The page cache time-to-live is set to 1 day. When the page is generated first time by jsps and tiles it is put into cache, and served for next 24 hours from the cache. After 24 hours it gets generated again. The manifestation of the bug is that randomly, the homepage gets generated as a blank page, about once in every 3 cache refreshes. When it occurs, the ByteArrayOutputStream has size 0, after the generation of the page has completed. Generating the homepage involves pulling some data from the database, which changes rarely, about once every week. I put cache time to live 300 seconds to eliminate the posibility that corrupt data from database causes errors in page generation. With 300 second time to live the problem was still there. The data in database does not change between good and faulty page generations. Home page is relatively simple - it does not involve pulling data from other data sources. It just reads some data the database and uses that data to make some html, using jsp. After turning on logging on database calls, all filters, and using a PrintWriter decorator inside our response wraper that echoes all print statements to the log, I found out something strange - A correct page generation logs some database calls (by the database logger), then a chunk of html (by the logging PrintWriter decorator, as a result of flushing JspWriter after enough out.write calls have been made), then some more database calls, then some more html.. and the page gets generated. ** A faulty generation (the one that produces a blank page) logs exactly same database calls as a correct page generation, but the log entries produced by the echoing PrintWriter are missing! **, like as jsps are executing normally, but something is wrong with the JspWriter out object. I am suspecting that somehow JspWriter writes somewhere else, not where it should. It should write into response wrapper's buffer, though the echoing/logging PrintWriter. But there is no PrintWriter echo and no bytes in response wrapper buffer... more exactly, *sometimes* there is no PrintWriter echo and no bytes in response wrapper buffer. I have read all the code that makes up the life cycle of PageContext and JspWriter on the docjar site (not sure for what version of Tomcat), and couldn't find anything that would help me solve this. http://www.docjar.com/html/api/org/apache/jasper/runtime/JspWriterImpl.java.html http://www.docjar.com/html/api/org/apache/jasper/runtime/PageContextImpl.java.html http://www.docjar.com/html/api/org/apache/jasper/runtime/JspFactoryImpl.java.html After adding some more logging statements I found out that 1 instance of JspWritter and 1 instance of PageContext are used shared across all page generations (site has low traffic and rarely 2 requests in same time). Same JspWritter and PageContext instances sometimes participate in good page and faulty page generations. I was hoping that someone on this list might know something that could help me find out why is this happening. Please help. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED
Re: Form authentication with captcha...
Hi David, I don't like realm because I don't want to implement a new authentication repository, I only want to implement a new authentication method. Doing this at the realm level limit the possibilities of the form, i want to do captcha validation when the user has has tw consecutive errors from the same IP. How realm can access this data? Thanks in advance. Ricardo. David Delbecq escribió: En l'instant précis du 04/07/07 10:15, rpr_listas s'exprimait en ces termes: Hello David, I know that this is out of the specification, and bind my application to this server implementation, but modify the realm has the same problem, transform my application in a tomcat-only application. Indeed it would make your application work only with server authentification that split password in 2 parts (password/captcha), but 1) it's easier to make and maintain a custom realm accros tomcat version than patch tomcat authentificator. 2) if you need to switch later from tomcat to jboss or other container, all you have is to recode for that server an equivalent of your realm (most server provide such support for user authentifications), while doing a fix similar to the one of authentificator might prove more difficult as not an expected point of extension. 3) If you limit change to realm, other webapplications can still run without trouble on your tomcat, this include the tomcat manager, tomcat admin, that are commonly deployed on tomcat. Build a custom authentication is not solution, because this disconnect the application from the J2EE standard, and I prefer to fit to standards in the rest of the application. I think that the better approach could be a custom authentication servlet and this servlet store a new Principal in the container. But i think that in J2EE can't access to do this from servlet. Indeed it can't really do it, but you could perhaps use and authentification filter like this: http://securityfilter.sourceforge.net/ There is even a discussion on how to pass additional arguments to it's authentification mecanism: http://sourceforge.net/forum/forum.php?thread_id=1527995forum_id=200424 Best regards. Ricardo David Delbecq escribió: Hello, Form authnetificator does form based authentification regarding the corresponding J2EE specifications, which specify the submit name of the username field (j_username), the submit name of the user password (j_passwrd), and that's all. Of course you, developper of webapplication can customize form (adding company logo, etc), but the specs states that user must provide username and password and submit it to /j_security_check url. Adding a captcha in this specs or other informations is not possible like that. The only 2 ways i see to add captcha and not break specs is either 1) to create a realm that expect the captcha to be appended or perpended to password. eg: j_username: johnSmith j_password: [EMAIL PROTECTED] The realm could probably compare the provided captcha with some value stored somewhere else the j_password field could be constructed, client side, with javascript, from 2 not submitted fields. or 2) Don't rely on container security and provide your own security with you own whatever forms. En l'instant précis du 03/07/07 10:45, rpr_listas s'exprimait en ces termes: Hi all! I'm thinking in implement a captcha (http://en.wikipedia.org/wiki/Captcha) protection for web-based authentication. I'm looking in the tomcat surce and the form authentication seems be implemented by org.apache.catalina.authenticator.FormAuthenticator class. But I'm not sure if change this class is the right way. Are there other better method to do this? Must I change the FormAutenticator class or must extend it in other class and i can refer to it in the tomcat configuration ? Thanks in advance and best regards. Ricardo.
Re: Form authentication with captcha...
Hello David, I know that this is out of the specification, and bind my application to this server implementation, but modify the realm has the same problem, transform my application in a tomcat-only application. Build a custom authentication is not solution, because this disconnect the application from the J2EE standard, and I prefer to fit to standards in the rest of the application. I think that the better approach could be a custom authentication servlet and this servlet store a new Principal in the container. But i think that in J2EE can't access to do this from servlet. Best regards. Ricardo David Delbecq escribió: Hello, Form authnetificator does form based authentification regarding the corresponding J2EE specifications, which specify the submit name of the username field (j_username), the submit name of the user password (j_passwrd), and that's all. Of course you, developper of webapplication can customize form (adding company logo, etc), but the specs states that user must provide username and password and submit it to /j_security_check url. Adding a captcha in this specs or other informations is not possible like that. The only 2 ways i see to add captcha and not break specs is either 1) to create a realm that expect the captcha to be appended or perpended to password. eg: j_username: johnSmith j_password: [EMAIL PROTECTED] The realm could probably compare the provided captcha with some value stored somewhere else the j_password field could be constructed, client side, with javascript, from 2 not submitted fields. or 2) Don't rely on container security and provide your own security with you own whatever forms. En l'instant précis du 03/07/07 10:45, rpr_listas s'exprimait en ces termes: Hi all! I'm thinking in implement a captcha (http://en.wikipedia.org/wiki/Captcha) protection for web-based authentication. I'm looking in the tomcat surce and the form authentication seems be implemented by org.apache.catalina.authenticator.FormAuthenticator class. But I'm not sure if change this class is the right way. Are there other better method to do this? Must I change the FormAutenticator class or must extend it in other class and i can refer to it in the tomcat configuration ? Thanks in advance and best regards. Ricardo. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAAS how to find user login name on the web app
Hi, lmk! Your JAAS module is a tomcat Realm? If you develop a tomcat realm you can access the user data via the standard servlet API. HttpServletRequest.getRemoteUser(); HttpServletRequest.getUserPrincipal(); regards. Ricardo. lmk escribió: Hii, I developed a JAAS module for authentication, and I deployed it on the tomcat server. I'd like to display the login name on the web app after authenticatiobn succeed.how to find it ..? can i finf it on the session?? or must use the Callbackhandler object..? regards!!! - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Images and response.getOutputStream()
Hi Lyallex!
You're getting a OutputStream ftrom a JSP? If the JSP has a simple
single empty line before your java code %%, the JSP framework get a
writer before your java code is executred. This is the cause of the
IllegalState Exception. The rigth way to do this is from a servlet, but
if you prefer still using JSP, clean any empty space before your java code.
This code probably fails:
[EMAIL PROTECTED] import ..
[EMAIL PROTECTED] ...
%
//my java code
%
EOF
An this avoid the problem:
%page %
//my java code
//other java line
%EOF
Best regards.
Ricardo
Lyallex escribió:
Hi
I'm not sure this is a Tomcat question, more likely a poor
understanding of
the Request/Response lifecycle on my part but I'll give it a go anyway.
After agonising for days(weeks) over whether to store my images in a
database or on the filesystem I opted for the database.
I have everything working fine ... apart from one little niggling
thing that
I just cannot figure out.
Every time I get an image from the database I get an exception
java.lang.IllegalStateException: getOutputStream() has already been
called
for this response ...
Now I think I understand why this is happening, I read somewhere that you
cannot get a JspWriter (via a call to the implicit object out for
example)
and a binary output stream
(ServletOutputStream outStream = response.getOutputStream ()) from the
same
response. Nothing falls over and the images appear fine. It's really the
exception traces I'm trying to get rid of
It appears that others are also using a database to store images and have
things working.
(mainly from http://marc.info/?l=tomcat-user)
Can anyone advise me as to how to write both text and image data out
to the
same response without this exception clogging up all my log files ?
I have included code below if you want/need to read it
Many thanks
Duncan
//== get an image in a jsp =
//where p is a Product Object that contains information on the image
name as
stored in the database
//images can be thumbnails or normal size
img
src=imageproxy.jsp?imageid=%=p.calculateImageId()%imagetype=thumb
width='80'
//== imageproxy.jsp
//where ImageServer is a singleton that gets an InputStream on a MySQL
database BLOB
boolean DEBUG = false;
ServletOutputStream outStream = response.getOutputStream();
response.reset();
response.setHeader(Expires, -1);
response.setHeader(Cache-Control, no-cache);
String imageId = request.getParameter (imageid);
String imageType = request.getParameter(imagetype);
ImageServer images = ImageServer.getServer();
InputStream inStream = images.getImageData(imageId, imageType);
if(DEBUG){
System.out.println(imageproxy.jsp, inStream has +
inStream.available() + bytes available);
}
byte[] bytes = new byte[1000];
int bytesRead = inStream.read(bytes);
while (bytesRead != -1) {
outStream.write(bytes,0,bytesRead);
bytesRead = inStream.read(bytes);
}
outStream.flush ();
inStream.close();
//= Just FYI here is the trace (one per image) =
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: getOutputStream() has already been
called
for this response
at org.apache.catalina.connector.Response.getWriter(Response.java
:599)
at org.apache.catalina.connector.ResponseFacade.getWriter(
ResponseFacade.java:195)
at org.apache.jasper.runtime.JspWriterImpl.initOut (
JspWriterImpl.java:124)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(
JspWriterImpl.java:117)
at org.apache.jasper.runtime.PageContextImpl.release(
PageContextImpl.java:191)
at
org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext (
JspFactoryImpl.java:115)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(
JspFactoryImpl.java:75)
at
org.apache.jsp.imageproxy_jsp._jspService(imageproxy_jsp.java:94)
at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java
:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.jasper.servlet.JspServletWrapper.service(
JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile (
JspServlet.java:314)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java :213)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:178)
