[OT] Looking for engineers in boston
Hey guys. Sorry for the spam. My company is looking for good engineers in boston. You can find the job posting details here: http://www.ifactory.com/about/jobs.php To be honest that job description is only half the picture. We also do a lot of: - Testing using TDD - Tapestry - Hibernate - Agile/iterative development including peer programming and code reviews It's a great, small company that really great to work at (we have a game room and a dedicated beer fridge). So send your resumes over to either me or [EMAIL PROTECTED] -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Response committed before getting to the filters
So every once in a while when you make a request to the server you won't get anything back and the log will show that one of the filters complained that response is already committed. So I restarted tomcat with the jpda debugger on, fired up my debugger in eclipse, and set a breakpoint at the place in the filter where this message is printed. My app has 2 filters right now and the breakpoint is in the second filter. So when I hit the breakpoint I went down in the stack trace to the point at which tomcat calls doFilter on the first filter in the filter chain. At that point is the stack, response.isCommitted() evaluates to 'true'(!?). Exploring the objects the response shows that the headers written so far are: Transfer-Encoding = chunked Date = Fri, 06 Oct 2006 14:33:33 GMT and contentLength == -1. Why would the response be committed before even getting to any of the code in my application? Even suggestions on what to investigate further would be help at this point. Thanks in advance. -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857 - 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: Response committed before getting to the filters
The source code for both is below (this code is actually from the spring
library if that makes any difference).
I really don't think the filters have anything to do with it. I just set
a conditional breakpoint in the first line of doFilter() in the first
filter that gets called by tomcat for when response.isCommitted()
evaluates to true. As soon as it happened again that breakpoint got hit
and response.isCommitted() was, in fact, true. But in every other normal
request the breakpoint never gets hit.
This is what the first filter does (sorry looks ugly in email):
public final void doFilter(ServletRequest request, ServletResponse
response, FilterChain filterChain)
throws ServletException, IOException {
if (!(request instanceof HttpServletRequest) || !(response
instanceof HttpServletResponse)) {
throw new ServletException(OncePerRequestFilter just supports
HTTP requests);
}
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
String alreadyFilteredAttributeName =
getAlreadyFilteredAttributeName();
if (request.getAttribute(alreadyFilteredAttributeName) != null ||
shouldNotFilter(httpRequest)) {
// proceed without invoking this filter
filterChain.doFilter(request, response);
}
else {
// invoke this filter
request.setAttribute(alreadyFilteredAttributeName, Boolean.TRUE);
doFilterInternal(httpRequest, httpResponse, filterChain);
}
}
and doFilterInternal() is:
protected void doFilterInternal(
HttpServletRequest request, HttpServletResponse response,
FilterChain filterChain)
throws ServletException, IOException {
SessionFactory sessionFactory = lookupSessionFactory(request);
Session session = null;
boolean participate = false;
if (isSingleSession()) {
// single session mode
if (TransactionSynchronizationManager.hasResource(sessionFactory))
{
// Do not modify the Session: just set the participate flag.
participate = true;
}
else {
logger.debug(Opening single Hibernate Session in
OpenSessionInViewFilter);
session = getSession(sessionFactory);
TransactionSynchronizationManager.bindResource(sessionFactory,
new SessionHolder(session));
}
}
else {
// deferred close mode
if (SessionFactoryUtils.isDeferredCloseActive(sessionFactory)) {
// Do not modify deferred close: just set the participate flag.
participate = true;
}
else {
SessionFactoryUtils.initDeferredClose(sessionFactory);
}
}
try {
filterChain.doFilter(request, response);
}
finally {
if (!participate) {
if (isSingleSession()) {
// single session mode
TransactionSynchronizationManager.unbindResource(sessionFactory);
logger.debug(Closing single Hibernate Session in
OpenSessionInViewFilter);
try {
closeSession(session, sessionFactory);
}
catch (RuntimeException ex) {
logger.error(Unexpected exception on closing Hibernate
Session, ex);
}
}
else {
// deferred close mode
SessionFactoryUtils.processDeferredClose(sessionFactory);
}
}
}
}
On Fri, 2006-10-06 at 11:00 -0400, David Smith wrote:
So what does the first filter do? Does it do anything with the response
before chaining to the second one?
--David
Dan Adams wrote:
So every once in a while when you make a request to the server you won't
get anything back and the log will show that one of the filters
complained that response is already committed. So I restarted tomcat
with the jpda debugger on, fired up my debugger in eclipse, and set a
breakpoint at the place in the filter where this message is printed.
My app has 2 filters right now and the breakpoint is in the second
filter. So when I hit the breakpoint I went down in the stack trace to
the point at which tomcat calls doFilter on the first filter in the
filter chain. At that point is the stack, response.isCommitted()
evaluates to 'true'(!?). Exploring the objects the response shows that
the headers written so far are:
Transfer-Encoding = chunked
Date = Fri, 06 Oct 2006 14:33:33 GMT
and contentLength == -1.
Why would the response be committed before even getting to any of the
code in my application? Even suggestions on what to investigate further
would be help at this point. Thanks in advance.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857
-
To start a new topic, e-mail: users
Re: Response committed before getting to the filters
So I set a conditional breakpoint for response.isCommitted() all the way
down in CoyoteAdapter.service() (called by Http11Processor.process())
and the response was committed at that point when this happened. Here is
the source where the breakpoint was:
// Parse and set Catalina and configuration specific
// request parameters
if ( postParseRequest(req, request, res, response) ) {
// Calling the container
// BREAKPOINT IS HERE
connector.getContainer().getPipeline().getFirst().invoke(request,
response);
}
I'm going to try to go ever further down and see if there is a point at
which it isn't committed.
On Fri, 2006-10-06 at 10:51 -0400, Dan Adams wrote:
So every once in a while when you make a request to the server you won't
get anything back and the log will show that one of the filters
complained that response is already committed. So I restarted tomcat
with the jpda debugger on, fired up my debugger in eclipse, and set a
breakpoint at the place in the filter where this message is printed.
My app has 2 filters right now and the breakpoint is in the second
filter. So when I hit the breakpoint I went down in the stack trace to
the point at which tomcat calls doFilter on the first filter in the
filter chain. At that point is the stack, response.isCommitted()
evaluates to 'true'(!?). Exploring the objects the response shows that
the headers written so far are:
Transfer-Encoding = chunked
Date = Fri, 06 Oct 2006 14:33:33 GMT
and contentLength == -1.
Why would the response be committed before even getting to any of the
code in my application? Even suggestions on what to investigate further
would be help at this point. Thanks in advance.
--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Resolved: Response committed before getting to the filters
Thankfully (and shamefully) it did in fact turn out to be something on
our end. Basically there was object that had a reference to the response
output stream that would close the stream when it was getting garbage
collected which had as a side effect that tomcat would set the response
that owned the stream as being committed already. Thanks for the help.
Lesson learned: double check that streams are closed correctly.
On Fri, 2006-10-06 at 12:33 -0400, Dan Adams wrote:
So I set a conditional breakpoint for response.isCommitted() all the way
down in CoyoteAdapter.service() (called by Http11Processor.process())
and the response was committed at that point when this happened. Here is
the source where the breakpoint was:
// Parse and set Catalina and configuration specific
// request parameters
if ( postParseRequest(req, request, res, response) ) {
// Calling the container
// BREAKPOINT IS HERE
connector.getContainer().getPipeline().getFirst().invoke(request,
response);
}
I'm going to try to go ever further down and see if there is a point at
which it isn't committed.
On Fri, 2006-10-06 at 10:51 -0400, Dan Adams wrote:
So every once in a while when you make a request to the server you won't
get anything back and the log will show that one of the filters
complained that response is already committed. So I restarted tomcat
with the jpda debugger on, fired up my debugger in eclipse, and set a
breakpoint at the place in the filter where this message is printed.
My app has 2 filters right now and the breakpoint is in the second
filter. So when I hit the breakpoint I went down in the stack trace to
the point at which tomcat calls doFilter on the first filter in the
filter chain. At that point is the stack, response.isCommitted()
evaluates to 'true'(!?). Exploring the objects the response shows that
the headers written so far are:
Transfer-Encoding = chunked
Date = Fri, 06 Oct 2006 14:33:33 GMT
and contentLength == -1.
Why would the response be committed before even getting to any of the
code in my application? Even suggestions on what to investigate further
would be help at this point. Thanks in advance.
--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tomcat not passing resources to my filters
Okay, I just set up a new tomcat with the latest version (5.5.20). My webapp is using urlrewritefilter. Whenever I request a url the filter will output what it's doing to the log even if it doesn't end up doing anything with a url. I've got this down to a base test case and what's happening is that if I request a url that does not end in .html then urlrewritefilter is called during the request and can do it's thing. But if the file ends .html then tomcat serves up the file as-is and the filter never even gets called. Is this something new? This seems to be something that has changed since 5.5.17 because it didn't do this then. Anyone have any ideas? -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Response already committed
I'm getting a problem that appears to occur randomly. If I request the same page in my webapp over and over most of the time it will come up fine but sometimes tomcat won't return anything and I'll get a blank page and this error in the log: Oct 3, 2006 4:20:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed It also happens for static files like stylesheets so sometimes you will request a page and then the styles won't get loaded. Anyone have any clues as to what this could be? I'm googling around and looking through my tomcat book but haven't found an answer yet. I'm using tomcat 5.5 with the mod_jk connector and apache 2. Here is my server.xml: Server port=8005 shutdown=SHUTDOWN GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources Service name=Catalina Connector port=8080 / !-- Define an AJP 1.3 Connector on port 8029 -- Connector port=8029 enableLookups=false redirectPort=8443 protocol=AJP/1.3 / !-- Define the top level container in our container hierarchy -- Engine name=Catalina defaultHost=localhost Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ Realm className=org.apache.catalina.realm.MemoryRealm / Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true / !-- Define the default virtual host Note: XML Schema validation will not work with Xerces 2.2. -- Host name=domain.company.com appBase=hosts/domain debug=0 unpackWARs=true autoDeploy=false Context path= docBase=. / /Host /Engine /Service /Server -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857 - 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: Response already committed
Hmm, I don't think that is the culprit. I think all of our stuff is thread safe. We're using a framework (Tapestry) which shields us from threading issues like that and prevents us from storing request stuff in the session. Also, if that were the case would that cause problems when loading static files? I don't think so. Also, we are using a filter which when it tries to do a redirect will throw an error complaining about this so this happens way before our app ever gets to do anything: ERROR: response is comitted cannot forward (this is a very strange problem!, check you haven't done anything to the response (ie, written to it) before here On Tue, 2006-10-03 at 15:39 -0500, Caldarale, Charles R wrote: From: Dan Adams [mailto:[EMAIL PROTECTED] Subject: Response already committed I'm getting a problem that appears to occur randomly. If I request the same page in my webapp over and over most of the time it will come up fine but sometimes tomcat won't return anything and I'll get a blank page and this error in the log: Oct 3, 2006 4:20:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Any chance that the logic in your servlet is not thread-safe? Repeatedly submitting requests could get more than one going at the same time, causing improperly scoped variables to be overwritten. For example, is request-specific data being stored in the session? - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
duplicate deploy with virtual hosts
Okay, I have a working configuration with 2 virtual hosts but I would like to have tomcat extract the wars automatically without auto-deploying them to their own webapps because this causes my applications to get launched twice each. I tried setting unpackWARs=true and deployOnStartup=false but then my apps don't get extracted. Any help would really be appreciated. -- Dan Adams Software Engineer Interactive Factory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk and url encoding
Okay, i'm using tomcat 5.5 and mod_jk with apache 2. It looks like I've got jk set up okay for the most part. I'm able to use the site as I did before switching to mod_jk except for one thing. When I try to access the following url I got a 404 from apache and tomcat never gets a chance to touch the url (I have a request dump valve in there dumping all requests): /sdirect/_sp=Shomesp=Sadmin%2FHome/admin/Home, $AdminBorder.$Nav.link.html now the problem is the %2F. If I replace that with a / like this it works fine: /sdirect/_sp=Shomesp=Sadmin/Home/admin/Home,$AdminBorder.$Nav.link.html I even tried adding JkOptions +ForwardUIREscaped to my httpd.conf with no luck. Any ideas on why this is not making it to tomcat when %2F is used?? I am really befuddled with this one. -- Dan Adams Software Engineer Interactive Factory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk and url encoding
got it. needed AllowEncodedSlashes On. On Tue, 2005-11-15 at 14:35 -0500, Dan Adams wrote: Okay, i'm using tomcat 5.5 and mod_jk with apache 2. It looks like I've got jk set up okay for the most part. I'm able to use the site as I did before switching to mod_jk except for one thing. When I try to access the following url I got a 404 from apache and tomcat never gets a chance to touch the url (I have a request dump valve in there dumping all requests): /sdirect/_sp=Shomesp=Sadmin%2FHome/admin/Home, $AdminBorder.$Nav.link.html now the problem is the %2F. If I replace that with a / like this it works fine: /sdirect/_sp=Shomesp=Sadmin/Home/admin/Home,$AdminBorder.$Nav.link.html I even tried adding JkOptions +ForwardUIREscaped to my httpd.conf with no luck. Any ideas on why this is not making it to tomcat when %2F is used?? I am really befuddled with this one. -- Dan Adams Software Engineer Interactive Factory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
