Re: svn commit: r965150 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/tomcat/util/net/ webapps/docs/ webapps/docs/config/
On 20.07.2010 08:35, jean-frederic clere wrote:
On 07/19/2010 07:16 PM, Mark Thomas wrote:
On 18/07/2010 23:50, Rainer Jung wrote:
On 18.07.2010 02:02, Mark Thomas wrote:
On 18/07/2010 00:57, ma...@apache.org wrote:
Author: markt
Date: Sat Jul 17 23:57:23 2010
New Revision: 965150
URL: http://svn.apache.org/viewvc?rev=965150&view=rev
Log:
Restore pero's timeout fix for the BIO connector. Add configuration
of the timeout.
Servlet TCK (with BIO) and unit tests pass as of this commit.
It is looking like timeouts are going to be required to fix
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567. The complete
fix is going to require some refactoring and I'm not quite there. It
does look like most of the fix for
https://issues.apache.org/bugzilla/show_bug.cgi?id=49528 is going to end
up being reverted.
Also, need to check the NIO and APR timeout async requests.
I'm not totally sure, but after JFC's heads up that the TCK fails
What heads up where?
That was more than 2 weeks ago. I need to retest with the actual code.
This stuff should be on the dev list. A simple "The
As JFC said: it was an old message (on the dev list):
http://apache.markmail.org/message/7t7l2oijwtsn6gp6
Servlet 3.0 TCK fails with the XXX connector." is fine on the dev list.
Which test with which connector?
It was with APR.
I did only check with BIO.
I had
a short look at the async timeout runnable. My impression was, that the
default value for the timeout is "-1" and this would let the timeout
condition in the runnable always trigger.
> From the top of page 14 of the servlet 3.0 spec:
AsyncContext.setTimeout(long)... A value of 0 or less indicates that the
asynchronous operation will never time out. ...
I couldn't find an explicit default.
Can't find it too.. Why not using 0 (for ever) or 1 minutes (to prevent
bad applications).
I was slightly confused by two possibly different notions of timeout,
the one in AsyncContext and the one in the AsyncTimeout runnable. I was
looking at the AsyncTimeout runnable in JIoEndpoint which contains:
if ((now-access)>socket.getTimeout()) {
processSocket(socket,SocketStatus.TIMEOUT);
}
So I thought since now>=access if the timeout is <=0 it will run
processSocket(socket,SocketStatus.TIMEOUT). This seems to end up in
CoyoteAdapter.asyncDispatch(*, *, SocketStatus.TIMEOUT), which calls
asyncContextImpl.setTimeoutState(). That in turn sets an internal state
that shortcuts doInternalDispatch() to fire a timeout event and return
an error.
The async context timeout seems to be set from the connector
asyncTimeout attribute (default 1) and never gets used directly.
But it is all tied together via the listener which is called when the
async context timeout is set. The listener is implemented in the
processor, which then sets the new timeout as a timeout to the socket,
so the two timeouts are actually the same at the end.
So: the default we use is 1, but if the timeout were <=0 then I
think the condition in the AsyncTimeout runnable would fail.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Not able to download eclipse-JDT-3.3.1.zip
Hi, I am trying to build Tomcat 6.0.x from trunk on Windows Vista svn checkout http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ Build is breaking as download for below file never ends http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip Please let me know how to get around it. I really appreciate the help. Thanks, Naveen
Re: Not able to download eclipse-JDT-3.3.1.zip
2010/7/20 Naveen Shirole :
> Hi,
> I am trying to build Tomcat 6.0.x from trunk on Windows Vista
> svn checkout http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
>
> Build is breaking as download for below file never ends
> http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
>
> Please let me know how to get around it. I really appreciate the help.
>
It is a big file. Either wait until the download finishes, or
a) download it separately
b) unpack as a subdirectory "eclipse" into your libraries directory
(aka ${base.path})
Once "eclipse/plugins/org.eclipse.jdt.core_3.3.1.v_780_R33x.jar" file
is present, the download will not be attempted anymore.
See "jdt.loc" and other "jdt.*" settings in build.properties.default
The http://archive.eclipse.org/... URL works for me. It is not broken.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49158] More than one JSESSIONID cookie headers set
https://issues.apache.org/bugzilla/show_bug.cgi?id=49158
davidconnard changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #7 from davidconnard 2010-07-20
10:14:30 EDT ---
Filip,
Your change doesn't actually do exactly what you think it does.
Your code - below - Response.java, line 992:
for (int i = 0; i < n; i++) {
if (headers.getName(i).toString().equals(headername)) {
if (headers.getValue(i).toString().startsWith(startsWith)) {
--> headers.setValue(sb.toString());
set = true;
}
}
}
Yes, setValue(contents) appears to be a logical call... however, that call is
actually setValue(name), and the returned contents are meant to be the
reference to the header (to which you can then add the value).
The result of that call is to add a header named, say:
JSESSIONID=54EDEDA814975EB485C2D9D660346717; Domain=.domain.com; Path=/
This doesn't actually appear to result in any additional response header
(presumably because the format was invalid, or the value was never set), and it
doesn't change the value of the existing Set-Cookie header. The following code
appears to work fine instead:
for (int i = 0; i < n; i++) {
if (headers.getName(i).toString().equals(headername)) {
if (headers.getValue(i).toString().startsWith(startsWith)) {
--> headers.getValue(i).setString(sb.toString());
set = true;
}
}
}
Note that you could probably optimise this (and avoid the set=true / later
addHeader() call by calling instead:
headers.setValue(name).setString(sb.toString())
This is proving to be critical to us (we manually invalidate sessions first
time around when we haven't seen them before - to guard against sessions being
presented from search engines), and we currently end up in an invalidation loop
as the second JSESSIONID is never actually presented back to the browser.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48379] Session cookie domain and path configuration support
https://issues.apache.org/bugzilla/show_bug.cgi?id=48379 davidconnard changed: What|Removed |Added CC||david.conn...@staff.rsvp.co ||m.au -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49613] Request.getAttributeNames() slows down some applications
https://issues.apache.org/bugzilla/show_bug.cgi?id=49613 --- Comment #6 from Remy Maucherat 2010-07-20 10:20:44 EDT --- Actually, the patch is appropriate for TC 6. I thought it should be in getAttribute, but this would interfere with the SSLAuthenticator. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49158] More than one JSESSIONID cookie headers set
https://issues.apache.org/bugzilla/show_bug.cgi?id=49158 davidconnard changed: What|Removed |Added CC||david.conn...@staff.rsvp.co ||m.au -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Not able to download eclipse-JDT-3.3.1.zip
Hi Konstantin,
Thanks for the pointers. Repeated tries from direct URL did not work for me.
Finally I downloaded just org.eclipse.jdt.core_3.3.1.v_780_R33x.jar and
placed it in hierarchy you mentioned. It worked!
There is definitely some issue downloading from India
http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
Thanks for the help!
Naveen
On Tue, Jul 20, 2010 at 7:24 PM, Konstantin Kolinko
wrote:
> 2010/7/20 Naveen Shirole :
> > Hi,
> > I am trying to build Tomcat 6.0.x from trunk on Windows Vista
> > svn checkout http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
> >
> > Build is breaking as download for below file never ends
> >
> http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
> >
> > Please let me know how to get around it. I really appreciate the help.
> >
>
> It is a big file. Either wait until the download finishes, or
> a) download it separately
> b) unpack as a subdirectory "eclipse" into your libraries directory
> (aka ${base.path})
> Once "eclipse/plugins/org.eclipse.jdt.core_3.3.1.v_780_R33x.jar" file
> is present, the download will not be attempted anymore.
> See "jdt.loc" and other "jdt.*" settings in build.properties.default
>
>
> The http://archive.eclipse.org/... URL works for me. It is not broken.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
DO NOT REPLY [Bug 49158] More than one JSESSIONID cookie headers set
https://issues.apache.org/bugzilla/show_bug.cgi?id=49158 Rainer Jung changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #8 from Rainer Jung 2010-07-20 10:48:17 EDT --- Thanks for the feedback. This has been noticed independently a few days ago (see https://issues.apache.org/bugzilla/show_bug.cgi?id=49598) and has been fixed in in r964733. We just now started voting for releasing 6.0.29 which will contain the fix. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
