[Bug 56189] Remove cpappend.bat
https://issues.apache.org/bugzilla/show_bug.cgi?id=56189 --- Comment #1 from Ognjen Blagojevic --- It seems that cpappend.bat was called in jasper.bat in 5.5.x series. It is not used anymore in 6.0.x and later. -- 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
[Bug 56088] AbstractQueryReport$StatementProxy throws exception on Object methods if statement is closed
https://issues.apache.org/bugzilla/show_bug.cgi?id=56088 --- Comment #1 from Lari Hotari --- Please fix this. This is causing a problem in Grails applications too, http://jira.grails.org/browse/GRAILS-11151 . This is related to Hibernate issue HHH-8853 and has a workaround in Hibernate 4.3.2 version (which hasn't been released yet.) The problem seems to be in StatementDecoratorInterceptor.StatementProxy https://github.com/apache/tomcat/blob/7884644627150716ec3ed8460ee845179cb5da9a/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementDecoratorInterceptor.java#L235 not allowing equals and hashCode calls after the statement has been closed. -- 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
[Bug 56088] AbstractQueryReport$StatementProxy throws exception on Object methods if statement is closed
https://issues.apache.org/bugzilla/show_bug.cgi?id=56088 Lari Hotari changed: What|Removed |Added CC||lari.hot...@sagire.fi -- 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
[Bug 56088] AbstractQueryReport$StatementProxy throws exception on Object methods if statement is closed
https://issues.apache.org/bugzilla/show_bug.cgi?id=56088 --- Comment #2 from Lari Hotari --- Another place where equals and hashCode should be allowed on the proxy after closing: https://github.com/apache/tomcat/blob/7cc49cba77c628207c3d91ad4d4e1f6b2186de94/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/AbstractQueryReport.java#L224 -- 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
[Bug 56190] Connection keep-alive not working with asynchronous servlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=56190 --- Comment #2 from Konstantin Kolinko --- > I get these headers in the response With those headers you have keep-alive enabled (as that is default if nothing else is specified in an HTTP/1.1 response, per HTTP/1.1 specification). So, what is your problem? > response is sent in chunked transfer encoding "Chunked encoding" just means that response length was not know at the moment when response had to be sent to client. E.g. if output stream was flushed before closing the connection. Both are valid responses. -- 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
[Bug 56187] Websocket text buffer maximum limit does not change from default 8192.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56187 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Mark Thomas --- Applications using the old API (in this case Atmosphere) have an API available to change the buffer size if they wish. Applications have an API they can use to output binary messages that bypasses the buffer entirely. The buffers are always used when writing text messages and may be used when writing binary messages. Tomcat imposes no limits on the size of a message that is written. The buffer merely controls the frame size when writing large text messages. As per the WebSocket specification, frames have no semantic meaning (ignoring extensions which complicate things slightly). Proxies may split frames or merge frames as they see fit. Therefore, I see no reason for Atmosphere to object to large text messages being split into multiple frames. -- 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: TldScanner + Config, was: Jasper Improvements
2014-02-27 10:17 GMT+04:00 Jeremy Boynes : > > I was thinking of supporting compile-on-start as a option where the > initializer would scan the war for JSP(x) files and initiate the compilation > during startup. This was intended for production use where use of JspC was > not practical (e.g. because the actual version of runtime is not known at > pre-compilation time) but where taking a hit on access would be undesirable. http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html -> "Background JSP compilation" Compiling can take notable time, so I think it wouldn't be good to delay application startup for that time. > I was thinking there to combine the TLD and JSP scans into one. Those are different scans. For TLDs you have to scan jar files. For JSPs you have to scan application resources. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56190] Connection keep-alive not working with asynchronous servlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=56190 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mark Thomas --- This is as per the Servlet specification. The response has to committed when the async context is completed. At this point the response body may not be fully written so chunked encoding has to be used. -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 Lorenzo changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #7 from Lorenzo --- (In reply to Mark Thomas from comment #6) > It has been three weeks without any further information provided. If the > information has not been provided by the time of the next 7.0.x release then > this issue will be closed as WONTFIX. Hi, I have the same error and I get it quite often. I use Tomcat 7.0.50 on a 64 bit machine. I have this log4j properties config, if you tell me how to change it to log the error I can provide the logs. # configure the daily rolling file appender log4j.rootLogger=FINE, RollingAppender # Set the priority for each package log4j.logger.org.apache.catalina.util.LifecycleBase=FINE, RollingAppender log4j.appender.RollingAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.RollingAppender.File=../logs/ApplicationWeb.log log4j.appender.RollingAppender.DatePattern='.'-MM-dd log4j.appender.RollingAppender.layout=org.apache.log4j.PatternLayout log4j.appender.RollingAppender.layout.ConversionPattern=[%p] %d %c %M - %m%n The staccktrace of the error I get is: java.lang.NullPointerException org.apache.catalina.session.ManagerBase.generateSessionId(ManagerBase.java:807) org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:653) org.apache.catalina.connector.Request.doGetSession(Request.java:2956) org.apache.catalina.connector.Request.getSession(Request.java:2320) org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:899) org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:911) com.abovo.gc.plata.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:47) -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 --- Comment #8 from Lorenzo --- (In reply to Mark Thomas from comment #6) > It has been three weeks without any further information provided. If the > information has not been provided by the time of the next 7.0.x release then > this issue will be closed as WONTFIX. Hi, I have the same error and I get it quite often. I use Tomcat 7.0.50 on a 64 bit machine. I have this log4j properties config, if you tell me how to change it to log the error I can provide the logs. # configure the daily rolling file appender log4j.rootLogger=FINE, RollingAppender # Set the priority for each package log4j.logger.org.apache.catalina.util.LifecycleBase=FINE, RollingAppender log4j.appender.RollingAppender=org.apache.log4j.DailyRollingFileAppender log4j.appender.RollingAppender.File=../logs/ApplicationWeb.log log4j.appender.RollingAppender.DatePattern='.'-MM-dd log4j.appender.RollingAppender.layout=org.apache.log4j.PatternLayout log4j.appender.RollingAppender.layout.ConversionPattern=[%p] %d %c %M - %m%n The staccktrace of the error I get is: java.lang.NullPointerException org.apache.catalina.session.ManagerBase.generateSessionId(ManagerBase.java:807) org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:653) org.apache.catalina.connector.Request.doGetSession(Request.java:2956) org.apache.catalina.connector.Request.getSession(Request.java:2320) org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:899) org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:911) com.abovo.gc.plata.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:47) -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 Lorenzo changed: What|Removed |Added CC||loreatt...@gmail.com, ||ma...@apache.org -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 Mark Thomas changed: What|Removed |Added CC|ma...@apache.org| --- Comment #9 from Mark Thomas --- It is extremely rude to add someone to a cc list for a bug without their permission. Repeat offenders will be blocked from further use of the ASF Bugzilla system. -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #10 from Mark Thomas --- This is either an application bug or a bug in com.abovo.gc.plata.filter.AuthenticationFilter that is retaining and using a reference to a request object from a previous request rather than using the request object for the current request. This is not a bug in Apache Tomcat. Further assistance is available from the Apache Tomcat users mailing list. -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 --- Comment #11 from Lorenzo --- Sorry, I tought that you could be interested in the opportunity to have some debug about the presumed error. I will keep investigate it. -- 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
svn commit: r1572574 - in /tomcat/trunk: bin/cpappend.bat webapps/docs/changelog.xml
Author: markt Date: Thu Feb 27 13:53:10 2014 New Revision: 1572574 URL: http://svn.apache.org/r1572574 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56189 Remove unused file. Removed: tomcat/trunk/bin/cpappend.bat Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1572574&r1=1572573&r2=1572574&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Thu Feb 27 13:53:10 2014 @@ -170,6 +170,10 @@ Update Commons DBCP 2 to snapshot 202 dated 26 Feb 2014. (markt) + +56189: Remove used file cpappend.bat from the distribution. +(markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5540 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1572574 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
Re: TldScanner + Config, was: Jasper Improvements
On Feb 27, 2014, at 4:09 AM, Konstantin Kolinko wrote: > 2014-02-27 10:17 GMT+04:00 Jeremy Boynes : >> >> I was thinking of supporting compile-on-start as a option where the >> initializer would scan the war for JSP(x) files and initiate the compilation >> during startup. This was intended for production use where use of JspC was >> not practical (e.g. because the actual version of runtime is not known at >> pre-compilation time) but where taking a hit on access would be undesirable. > > http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html > -> "Background JSP compilation" > > Compiling can take notable time, so I think it wouldn't be good to > delay application startup for that time. I had in mind a production configuration where the JSPs are not expected to change between deployments. IIRC, background compilation only works with JSPs that have already been hit so there is still a compilation delay on first touch. This adds jitter to the latency timings for an application. The idea was to avoid that by compiling everything during startup before the application starts taking live traffic. As you say, this would slow startup down but (assuming multiple hosts or parallel deployment) would not impact user requests. A variation would be to kick off a background task so that startup is not delayed. > >> I was thinking there to combine the TLD and JSP scans into one. > > Those are different scans. > For TLDs you have to scan jar files. > For JSPs you have to scan application resources. TldScanner#scanResourcePaths has to scan all application resources under /WEB-INF as well. For a MVC-style application where the JSPs are under /WEB-INF there can be substantial overlap. — Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r1572659 - /tomcat/jk/trunk/native/common/jk_version.h
Author: mturk Date: Thu Feb 27 17:18:49 2014 New Revision: 1572659 URL: http://svn.apache.org/r1572659 Log: Prepare for release Modified: tomcat/jk/trunk/native/common/jk_version.h Modified: tomcat/jk/trunk/native/common/jk_version.h URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_version.h?rev=1572659&r1=1572658&r2=1572659&view=diff == --- tomcat/jk/trunk/native/common/jk_version.h (original) +++ tomcat/jk/trunk/native/common/jk_version.h Thu Feb 27 17:18:49 2014 @@ -29,7 +29,7 @@ #define JK_VERFIX 39 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 0 +#define JK_VERISRELEASE 1 /* Beta number */ #define JK_VERBETA 0 #define JK_BETASTRING "0" - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1572661 - /tomcat/jk/tags/JK_1_2_39/
Author: mturk Date: Thu Feb 27 17:20:08 2014 New Revision: 1572661 URL: http://svn.apache.org/r1572661 Log: Tag Tomcat Connectors 1.2.39 Added: tomcat/jk/tags/JK_1_2_39/ - copied from r1572660, tomcat/jk/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1572662 - in /tomcat/jk/trunk/native: STATUS.txt common/jk_version.h configure.ac iis/installer/isapi-redirector-win32-msi.ism
Author: mturk Date: Thu Feb 27 17:22:03 2014 New Revision: 1572662 URL: http://svn.apache.org/r1572662 Log: Bump version numbers Modified: tomcat/jk/trunk/native/STATUS.txt tomcat/jk/trunk/native/common/jk_version.h tomcat/jk/trunk/native/configure.ac tomcat/jk/trunk/native/iis/installer/isapi-redirector-win32-msi.ism Modified: tomcat/jk/trunk/native/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/STATUS.txt?rev=1572662&r1=1572661&r2=1572662&view=diff == --- tomcat/jk/trunk/native/STATUS.txt (original) +++ tomcat/jk/trunk/native/STATUS.txt Thu Feb 27 17:22:03 2014 @@ -18,7 +18,8 @@ Last modified at [$Date$] Release: -1.2.39 : in development +1.2.40 : in development +1.2.39 : in release process 1.2.38 : not released 1.2.37 : released May 31, 2012 1.2.36 : released May 14, 2012 Modified: tomcat/jk/trunk/native/common/jk_version.h URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_version.h?rev=1572662&r1=1572661&r2=1572662&view=diff == --- tomcat/jk/trunk/native/common/jk_version.h (original) +++ tomcat/jk/trunk/native/common/jk_version.h Thu Feb 27 17:22:03 2014 @@ -26,10 +26,10 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 -#define JK_VERFIX 39 +#define JK_VERFIX 40 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ -#define JK_VERISRELEASE 1 +#define JK_VERISRELEASE 0 /* Beta number */ #define JK_VERBETA 0 #define JK_BETASTRING "0" Modified: tomcat/jk/trunk/native/configure.ac URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/configure.ac?rev=1572662&r1=1572661&r2=1572662&view=diff == --- tomcat/jk/trunk/native/configure.ac (original) +++ tomcat/jk/trunk/native/configure.ac Thu Feb 27 17:22:03 2014 @@ -23,7 +23,7 @@ AC_PREREQ(2.59) dnl package and version. dnl synchronization with common/jk_version.h ? -AC_INIT([mod_jk], [1.2.39]) +AC_INIT([mod_jk], [1.2.40]) AC_CONFIG_SRCDIR([common/jk_worker.h]) AC_CONFIG_HEADER(common/config.h) Modified: tomcat/jk/trunk/native/iis/installer/isapi-redirector-win32-msi.ism URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/installer/isapi-redirector-win32-msi.ism?rev=1572662&r1=1572661&r2=1572662&view=diff == --- tomcat/jk/trunk/native/iis/installer/isapi-redirector-win32-msi.ism (original) +++ tomcat/jk/trunk/native/iis/installer/isapi-redirector-win32-msi.ism Thu Feb 27 17:22:03 2014 @@ -3425,7 +3425,7 @@ TQBzAGkAAQBSAGUAbABlAGEAcwBlAA== ProductIDnone ProductLanguage1033 ProductNameTomcat Isapi Redirector - ProductVersion1.2.39 + ProductVersion1.2.40 ProgressType0install ProgressType1Installing ProgressType2installed - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56189] Remove cpappend.bat
https://issues.apache.org/bugzilla/show_bug.cgi?id=56189 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Konstantin Kolinko --- Done in trunk by r1572574 . This change will be in 8.0.4. -- 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: Connectors, blocking, and keepalive
Mark, On 2/25/14, 3:31 AM, Mark Thomas wrote: > On 25/02/2014 06:03, Christopher Schultz wrote: >> All, > >> I'm looking at the comparison table at the bottom of the HTTP >> connectors page, and I have a few questions about it. > >> First, what does "Polling size" mean? > > Maximum number of connections in the poller. I'd simply remove it from > the table. It doesn't add anything. Okay, thanks. >> Second, under the NIO connector, both "Read HTTP Body" and "Write >> HTTP Response" say that they are "sim-Blocking"... does that mean >> that the API itself is stream-based (i.e. blocking) but that the >> actual under-the-covers behavior is to use non-blocking I/O? > > It means simulated blocking. The low level writes use a non-blocking > API but blocking is simulated by not returning to the caller until the > write completes. That's what I was thinking. Thanks for confirming. >> It is important to make that distinction since the end user (the >> code) can't tell the difference? > > The end user shouldn't be able to tell the difference. It is important > and it indicates that there is some overhead associated with the process. Aah, okay. A "true" blocking read or write would be more efficient, but you can't have both blocking and non-blocking operations on a connection after it's been established? >> Third, under "Wait for next Request", only the BIO connector says >> "blocking". Does "Wait for next Request" really mean >> wait-for-next-keepalive-request-on-the-same-connection? That's the >> only thing that would make sense to me. > > Correct. Good. >> Fourth, the "SSL Handshake" says non-blocking for NIO but blocking >> for the BIO and APR connectors. Does that mean that SSL handshaking >> with the NIO connector is done in such a way that it does not >> tie-up a thread from the pool for the entire SSL handshake and >> subsequent request? Meaning that the thread(s) that handle the SSL >> handshake may not be the same one(s) that begin processing the >> request itself? > > Correct. Once request processing starts (i.e. after the request > headers have been read) the same thread is used. Up to that point, > different threads may be used as the input is read (with the NIO > connector) using non-blocking IO. Good. Are there multiple stages of SSL handshaking (I know there are at the TCP/IP and SSL level themselves -- I mean in the Java code to set it up) where multiple threads could participate -- serially, of course -- in the handshake? I want to develop a pipeline diagram and want to make sure it's accurate. If the (current) reality is that a single thread does the SSL handshake and then another thread (possibly the same one) handles the actual request, then the diagram will be simpler. Let me take this opportunity to mention that while I could go read the code, I've never used Java's NIO package and would probably spend a lot of time figuring out basic things instead of answering the higher-level questions I'd like to handle, here. Not to mention that the connector-related code is more complicated than one would expect given the fairly small perceived set of requirements they have (i.e. take an incoming connection and allocate a thread, then dispatch). It's obviously far more complicated than that and there is a lot of code to handle some very esoteric requirements, etc. I appreciate you taking the time to answer directly instead of recommending that I read the code. You are saving me an enormous amount of time. ;) >> Lastly, does anything change when Websocket is introduced into the >> mix? > > Yes. Lots. > >> For example, when a connection is upgraded from HTTP to Websocket, >> is there another possibility for thread-switching or anything like >> that? > > Yes. Everything switches to non-blocking mode (or simulated > non-blocking in the case of BIO). > >> Or is the upgrade completely-handled by the request-processing >> thread that was already assigned to handle the HTTP request? > > The upgrade process is handled by the request processing thread but > once the upgrade is complete (i.e. the 101 response has been returned) > that thread returns to the pool. Okay, so the upgrade occurs and the remainder of the request gets re-queued. Or, rather, a thread is re-assigned when an IO event occurs. Is there any priority assigned to events, or are they processed essentially serially, in the order that they occurred -- that is, dispatched to threads from the pool in the order that the IO events arrived? >> Also, (forgive my Websocket ignorance) once the connection has been >> upgraded for a single request, does it stay upgraded or is the next >> (keepalive) request expected to be a regular HTTP request that can >> also be upgraded? > > The upgrade is permanent. When the WebSocket processing ends, the > socket is closed. Okay, so if a client played its cards right, it could send a traditional HTTP request with keepalive, make several more requests over the same connection, and then finally u
Re: Connectors, blocking, and keepalive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/02/2014 17:56, Christopher Schultz wrote:
> On 2/25/14, 3:31 AM, Mark Thomas wrote:
>> On 25/02/2014 06:03, Christopher Schultz wrote:
>>> It is important to make that distinction since the end user
>>> (the code) can't tell the difference?
>>
>> The end user shouldn't be able to tell the difference. It is
>> important and it indicates that there is some overhead associated
>> with the process.
>
> Aah, okay. A "true" blocking read or write would be more efficient,
> but you can't have both blocking and non-blocking operations on a
> connection after it's been established?
Java NIO provides no way of doing a true blocking read.
>>> Fourth, the "SSL Handshake" says non-blocking for NIO but
>>> blocking for the BIO and APR connectors. Does that mean that
>>> SSL handshaking with the NIO connector is done in such a way
>>> that it does not tie-up a thread from the pool for the entire
>>> SSL handshake and subsequent request? Meaning that the
>>> thread(s) that handle the SSL handshake may not be the same
>>> one(s) that begin processing the request itself?
>>
>> Correct. Once request processing starts (i.e. after the request
>> headers have been read) the same thread is used. Up to that
>> point, different threads may be used as the input is read (with
>> the NIO connector) using non-blocking IO.
>
> Good. Are there multiple stages of SSL handshaking (I know there
> are at the TCP/IP and SSL level themselves -- I mean in the Java
> code to set it up) where multiple threads could participate --
> serially, of course -- in the handshake? I want to develop a
> pipeline diagram and want to make sure it's accurate. If the
> (current) reality is that a single thread does the SSL handshake
> and then another thread (possibly the same one) handles the actual
> request, then the diagram will be simpler.
There are multiple stages in the handshake but as far as Tomcat is
concerned is does these:
start handshake
while (need to read more data to complete handshake) {
read data
try and do more of the handshake
}
Each iteration of that loop may be handled by a different thread (with
the socket going back to the poller if there is no data available at
the moment). So it could be one thread, it could be as many threads as
there are bytes in the handshake.
> Let me take this opportunity to mention that while I could go read
> the code, I've never used Java's NIO package and would probably
> spend a lot of time figuring out basic things instead of answering
> the higher-level questions I'd like to handle, here. Not to mention
> that the connector-related code is more complicated than one would
> expect given the fairly small perceived set of requirements they
> have (i.e. take an incoming connection and allocate a thread, then
> dispatch). It's obviously far more complicated than that and there
> is a lot of code to handle some very esoteric requirements, etc.
>
> I appreciate you taking the time to answer directly instead of
> recommending that I read the code. You are saving me an enormous
> amount of time. ;)
I was tempted to say go and read the code but I know from experience
that is a time consuming task. The refactoring I did to reduce code
duplication was immensely instructive. I still get lost in that code
sometimes but it happens a lot less often.
>> The upgrade process is handled by the request processing thread
>> but once the upgrade is complete (i.e. the 101 response has been
>> returned) that thread returns to the pool.
>
> Okay, so the upgrade occurs and the remainder of the request gets
> re-queued. Or, rather, a thread is re-assigned when an IO event
> occurs.
Correct.
> Is there any priority assigned to events, or are they processed
> essentially serially, in the order that they occurred -- that is,
> dispatched to threads from the pool in the order that the IO events
> arrived?
It is the same poller as for the HTTP connections. Roughly they'll be
processed in arrival order but there may be a little re-ordering. It
depends on the behaviour of the selector.
>>> Also, (forgive my Websocket ignorance) once the connection has
>>> been upgraded for a single request, does it stay upgraded or is
>>> the next (keepalive) request expected to be a regular HTTP
>>> request that can also be upgraded?
>>
>> The upgrade is permanent. When the WebSocket processing ends,
>> the socket is closed.
>
> Okay, so if a client played its cards right, it could send a
> traditional HTTP request with keepalive, make several more requests
> over the same connection, and then finally upgrade to Websocket for
> the final request. After that, the connection is terminated
> entirely.
Yes.
> There is an implication there that if you want to use Websocket,
> don't use it for tiny request/response activities because
> performance will actually drop. One would be foolish to "replace"
> plain-old HTTP with Websocket but try to treat them the same.
Lots of tiny
svn commit: r1572716 - in /tomcat/tc7.0.x/trunk: ./ bin/cpappend.bat webapps/docs/changelog.xml
Author: markt Date: Thu Feb 27 20:14:58 2014 New Revision: 1572716 URL: http://svn.apache.org/r1572716 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56189 Remove unused file. Removed: tomcat/tc7.0.x/trunk/bin/cpappend.bat Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1571196,1572574 Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1572716&r1=1572715&r2=1572716&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Feb 27 20:14:58 2014 @@ -155,6 +155,10 @@ Allow to limit JUnit test run to a number of selected test case methods. (kkolinko) + +56189: Remove used file cpappend.bat from the distribution. +(markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56189] Remove cpappend.bat
https://issues.apache.org/bugzilla/show_bug.cgi?id=56189 --- Comment #3 from Mark Thomas --- Fixed in 7.0.x for 7.0.53 onwards. -- 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
[Bug 56189] Remove cpappend.bat
https://issues.apache.org/bugzilla/show_bug.cgi?id=56189 Ognjen Blagojevic changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Ognjen Blagojevic --- Thank you. -- 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
svn commit: r1572776 - /tomcat/trunk/java/org/apache/tomcat/util/scan/Jar.java
Author: kkolinko
Date: Thu Feb 27 23:03:39 2014
New Revision: 1572776
URL: http://svn.apache.org/r1572776
Log:
Correct a pair of comment typos
Modified:
tomcat/trunk/java/org/apache/tomcat/util/scan/Jar.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/Jar.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/Jar.java?rev=1572776&r1=1572775&r2=1572776&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/Jar.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/Jar.java Thu Feb 27 23:03:39
2014
@@ -94,10 +94,10 @@ public interface Jar {
/**
* Obtain, in String form, the URL for an entry in this JAR. Note that for
- * JARs nested in WAR files, the Tomact specific war:file:... form will not
+ * JARs nested in WAR files, the Tomcat specific war:file:... form will not
* be used, rather the jar:jar:file:... form (that the JRE does not
* understand will be used). Note that this means that any code using these
- * URLs will need to understand the jar;jar:file:... form and use the
+ * URLs will need to understand the jar:jar:file:... form and use the
* {@link JarFactory} to ensure resources are accessed correctly.
*
* @param entry The entry to generate the URL for
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1572779 - /tomcat/trunk/webapps/docs/jasper-howto.xml
Author: kkolinko Date: Thu Feb 27 23:16:33 2014 New Revision: 1572779 URL: http://svn.apache.org/r1572779 Log: Followup to r1570175 Update compilerSourceVM and compilerTargetVM values in jasper-howto.xml as well. Modified: tomcat/trunk/webapps/docs/jasper-howto.xml Modified: tomcat/trunk/webapps/docs/jasper-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/jasper-howto.xml?rev=1572779&r1=1572778&r2=1572779&view=diff == --- tomcat/trunk/webapps/docs/jasper-howto.xml (original) +++ tomcat/trunk/webapps/docs/jasper-howto.xml Thu Feb 27 23:16:33 2014 @@ -106,10 +106,10 @@ set then setenv.[sh|bat] sh to the CLASSPATH environment variable. compilerSourceVM - What JDK version are the source files -compatible with? (Default value: 1.6) +compatible with? (Default value: 1.7) compilerTargetVM - What JDK version are the generated files -compatible with? (Default value: 1.6) +compatible with? (Default value: 1.7) development - Is Jasper used in development mode? If true, the frequency at which JSPs are checked for modification may be specified via - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56199] New: Implement validateXml option in JspC, or remove it from documentation
https://issues.apache.org/bugzilla/show_bug.cgi?id=56199 Bug ID: 56199 Summary: Implement validateXml option in JspC, or remove it from documentation Product: Tomcat 8 Version: 8.0.3 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com (In followup to r1570163 ) There are two places where "validateXml" option of Jasper is still mentioned in Tomcat 8: 1) res/deployer/build.xml line 58 2) webapps/docs/jasper-howto.xml line 273 In Tomcat 8 Jasper does not parse web.xml when invoked within a web application, but it parses it when it is invoked as JspC. In the latter case it makes some sense to restore the "validateXml" option. The place is org/apache/jasper/servlet/JspCServletContext # buildMergedWebXml() > WebXmlParser webXmlParser = new WebXmlParser(false, false, blockExternal); -- 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
svn commit: r1572787 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Thu Feb 27 23:56:15 2014 New Revision: 1572787 URL: http://svn.apache.org/r1572787 Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1572787&r1=1572786&r2=1572787&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Feb 27 23:56:15 2014 @@ -40,6 +40,16 @@ PATCHES PROPOSED TO BACKPORT: +1: kkolinko -1: +* https://issues.apache.org/bugzilla/show_bug.cgi?id=56199 + http://tomcat.markmail.org/thread/ydrqotnjkmdl6err + Restore validateXml option in Jasper. + Motivation: It is mentioned in documentation and some users complained on + removal of this option in Tomcat 7, as that broke their build scripts. + (The r1564747 backport proposal above have to be applied first, as it + modified adjacent lines to this one) + http://svn.apache.org/r1570163 + +1: kkolinko + -1: PATCHES/ISSUES THAT ARE STALLED: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5541 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1572776 Blamelist: kkolinko Build succeeded! sincerely, -The Buildbot
