[CONF] Apache Tomcat > Servlet TCK 5.0

[Remy Maucherat (Confluence)]

Title: Message Title



 
 
 
There's 1 new comment on this page 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Servlet TCK 5.0 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Remy Maucherat  
 
 
  
 
 

 
 
 
 
 
 
 
 
  https://github.com/eclipse-ee4j/jakartaee-tck/pull/338/files#diff-89fad4e6a2e15e52564d819014661653  Ouch ...For default-context-path, I obviously hate this feature, whatever is done it will have to be a mess. First thing would be to add it to WebXml, the parser and the Context. Then figure out how workable it is to change the mapping.  
 
 
  
 
 
  
 
 

 
 
 
 
 
 
 
 
Reply
• 
 
 
 
 
 
 
Like 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
View comment 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 7.5.0  
 
 
  
 
 
 
 
 
 
 
 
 

Re: Serving gz files in DefaultServlet (Re: r1531115, BZ 54095)

[Remy Maucherat]

On Sun, 2013-10-13 at 16:03 +0100, Mark Thomas wrote:
> I disagree since:
> - this is only in 8.0.x and we haven't had a stable release yet.
> - the user has to create the gzip'd version which is unlikely to exist
> be default before this feature does anything

I also think it should be disabled by default in all branches.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [WS] To flush or not to flush

[Remy Maucherat]

On Tue, 2013-09-24 at 06:34 -0700, Mark Thomas wrote:
> Non-blocking IO with non-upgraded streams still uses the standard
> buffering mechanisms.
> 
> I agree some clarification is required. When section 5.1 discusses
> buffering, it does so in the context of the ServletResponse object so it
> isn't immediately obvious how the buffer should be controlled (or even
> if it should exist) in the upgraded scenario.

Yes, that's correct, everything is described with the Servlet POV, so
the upgraded mode is undefined as far as buffering goes (so unbuffered
is correct).

Assuming a buffering scenario, I could add sos.flush() (which is a noop
currently) on line 92 in WsRemoteEndpointImplServer, that looks to me
the right location.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[WS] To flush or not to flush

[Remy Maucherat]

Hi Mark,

Unless I missed something, Websockets 1.0 on Servlet 3.1 upgrade doesn't
do much flushing, so that the IS/OS used in upgrade must effectively
just write immediately the data (and ensure it is really sent over the
wire).

I find that a bit weird, since during the design of Servlets 3.1, the
idea was to retain buffering. Of course, upgrade was then added, char
support was taken out of the new IO, and it should be feasible to use
this sort of bufferless streams in upgraded mode. But that's a lot of
assumptions, shouldn't the websockets implementation just flush ? In any
case it would be good to have the buffer vs no buffer choice clarified
for the upgraded mode [to be honest, I thought it was like the regular
Servlet 3.1 IO mode, minus the HTTP transfer encodings].

Thanks,
Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: SCI discovery ordering

[Remy Maucherat]

On Fri, 2013-09-20 at 08:38 +0100, Mark Thomas wrote:
> a) The container defined SCIs need to be loaded first. Any other
> solution places an unnecessary burden on application developers. It is
> reasonable for application developers to expect that if a container
> advertises support for WebSocket, JSP, etc. then those features are
> available when the application's SCI's are executed.

I agree the SCIs that may be used for core functionality should be
loaded first. Since that's now the design choice for JSP and WS, that
would make 1) JSP 2) WS 3) anything else.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1518214 - /tomcat/trunk/java/org/apache/jasper/el/ELContextImpl.java

[Remy Maucherat]

On Wed, 2013-08-28 at 14:14 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Aug 28 14:14:09 2013
> New Revision: 1518214
> 
> URL: http://svn.apache.org/r1518214
> Log:
> Add new resolvers to default resolver (bug spotted by remm)

>  DefaultResolver = new CompositeELResolver();
> +((CompositeELResolver) DefaultResolver).add(
> +ELManager.getExpressionFactory().getStreamELResolver());
> +((CompositeELResolver) DefaultResolver).add(new 
> StaticFieldELResolver());
>  ((CompositeELResolver) DefaultResolver).add(new MapELResolver());
>  ((CompositeELResolver) DefaultResolver).add(new 
> ResourceBundleELResolver());
>  ((CompositeELResolver) DefaultResolver).add(new 
> ListELResolver());

Nice. I was not sure ExpressionFactory.newInstance was a good idea (in
particular, it's slow).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1504148 - in /tomcat/trunk: java/org/apache/jasper/compiler/ java/org/apache/jasper/el/ java/org/apache/jasper/runtime/ test/javax/el/ test/org/apache/el/ test/org/apache/el/parser/ t

[Remy Maucherat]

On Wed, 2013-07-17 at 14:14 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Jul 17 14:14:28 2013
> New Revision: 1504148
> 
> URL: http://svn.apache.org/r1504148
> Log:
> Add the two new resolver types (stream and static) to Jasper in the correct 
> order and modify JasperELResolver so the correct resolvers are skipped.

> -public static ELResolver getDefaultResolver() {
> +public static ELResolver getDefaultResolver(ExpressionFactory factory) {
>  if (Constants.IS_SECURITY_ENABLED) {
>  CompositeELResolver defaultResolver = new CompositeELResolver();
> -// TODO ExpressionFactory.getStreamELResolver()
> -// TODO javax.el.StaticFieldResolver
> +defaultResolver.add(factory.getStreamELResolver());
> +defaultResolver.add(new StaticFieldELResolver());
>  defaultResolver.add(new MapELResolver());
>  defaultResolver.add(new ResourceBundleELResolver());
>  defaultResolver.add(new ListELResolver());

I see one issue: in most cases (= no security manager), the static
"cache" resolver instance is used, and it doesn't have the two new
resolvers. The new stream EL resolver for the collections seems to be
more difficult to use with the caching strategy as well, but it looks
possible.

Ideas ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.0.0-RC1

[Remy Maucherat]

On Thu, 2013-08-01 at 22:53 +0200, Mark Thomas wrote:
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC1/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-048/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC1/
> 
> The proposed 8.0.0-RC1 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 8.0.0-RC1 alpha

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Timeline for beginning EL 3.0 implementation?

[Remy Maucherat]

On Tue, 2013-06-11 at 21:36 +0100, Mark Thomas wrote:
> Once all that is done I was thinking about some form of alpha release 
> before starting work on the EL stuff.

I tested the EL 3 RI with Jasper, and (as expected) it is still as
pluggable as it used to, and it works well.

The amount of new stuff in the spec document did sound scary, but after
looking at the actual EL3 implementation compared to EL2, it was not so
bad.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Automatic deployment changes

[Remy Maucherat]

On Tue, 2013-05-07 at 13:54 +0100, Mark Thomas wrote:
> What has made changes in this area difficult in the past is a) a lack of
> a clear definition as to what the expected behaviour is and b) a lack of
> test cases to validate that behaviour.

a) is very true ...
Anyway, I think it's very good to specify it.

OTOH, the application server I know about uses marker files to expose
the deployment state, allow the user to manage them, and also (perhaps
more importantly) copies the said deployments to an internal location
(something which I obviously chose to avoid at all costs in Tomcat when
I did the deployer hacks). That sort of behavior is a possible option,
but I'm not sure it fits Tomcat well.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.37

[Remy Maucherat]

On Mon, 2013-04-29 at 12:17 +0200, jean-frederic clere wrote:
> The candidates binaries are available here:
> http://people.apache.org/~jfclere/tomcat-6/v6.0.37/
> 
> According to the release process, the 6.0.37 build corresponding to the
> tag TOMCAT_6_0_37 is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [X] Stable

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Servlet 3.1 tests

[Remy Maucherat]

On Wed, 2013-04-10 at 21:41 -0400, Mark Thomas wrote:
> On 10/04/2013 09:43, Remy Maucherat wrote:
> > Hi,
> >
> > Are there any good Servlet 3.1 tests around ? (besides the websockets
> > impl)
> 
> Not yet. We have Filip's initial implementation and a few associated 
> tests but that is it. The Servlet 3.1 NIO stuff is next on my TODO list 
> after the WebSocket work. That should generate a few tests. I suspect 
> that as folks start to use the new API there will be various bug reports 
> around the edge cases and they will generate a fair few tests.
> 
> The biggest problem with using WebSocket to test servlet 3.1 is that the 
> Servlet[Input|Output]Stream implementations are separate for HTTP 
> upgrade and async.

Ok, thanks. I indeed found one test which actually looks good
(TestNonBlockingAPI). Yes, I see why an upgrade test like websockets
does not fully apply to the usage inside a Servlet since the code is
indeed separate.

> > I doubt the Servlet TCK will have that sort of stuff, Servlet 3.0 wasn't
> > very good for that beyond testing of a few specific aspects.
> 
> I have access to the Servlet 3.1 draft TCK but haven't looked at it yet.

I haven't looked either, but I hope you're not expecting much.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Servlet 3.1 tests

[Remy Maucherat]

Hi,

Are there any good Servlet 3.1 tests around ? (besides the websockets
impl)

I doubt the Servlet TCK will have that sort of stuff, Servlet 3.0 wasn't
very good for that beyond testing of a few specific aspects.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1459043 - /tomcat/trunk/test/org/apache/catalina/core/TesterContext.java

[Remy Maucherat]

On Wed, 2013-03-20 at 20:46 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Mar 20 20:46:04 2013
> New Revision: 1459043
> 
> URL: http://svn.apache.org/r1459043
> Log:
> Add new methods
> 
> Modified:
> tomcat/trunk/test/org/apache/catalina/core/TesterContext.java

Sorry about that ...

I'm not sure this is a very good idea, but OTOH I'm quite sure this is
meant to be injected, so I added the get/set.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Strange APR/native behaviour

[Remy Maucherat]

On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote:
> > I mean check for Socket.setsbb somewhere after the socket is
> > returned from poller. Either the new buffer has been set or
> > the buffer address is different because of Socket.sendbb's offset param
> > (in this case it would be -11530560 so some wrong calculation)
> > 
> > Inside Socket.setsbb we get the ByteBuffer's direct address and later
> > reuse it inside Socket.sendbb(long socket, int offset, int len) call
> > by using 'socket->jsbuff + offset' and that offseted address is
> > displayed in
> > the upper debug trace (and if they are not the same OpenSSL will return
> > SSL_ERROR_SSL)
> 
> I'm using Socket.send() with the same buffer.
> 
> I'm looking at switching to sendb instead.

If you spare some time to refactor and use sendsbb next after trying
sendb, it's supposed to be faster [I never did a real comparison test
though].

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Strange APR/native behaviour

[Remy Maucherat]

On Tue, 2013-03-12 at 13:25 +, Mark Thomas wrote:
> Thanks for the pointers. I tried a few of them (the less invasive ones)
> with no luck. I'm putting together a test case that demonstrates the
> problem. That should make it very simple to determine if the root cause
> lies in APR or my code.

Ok, too bad. I was thinking the timeout trick could do it since the
"proper" non blocking option + EAGAIN didn't work that well for me then.
But that was a while ago. Using a 0 timeout is simpler overall, but
obviously it looks like a hack.

Yes, if you can write a simple test case, it would probably be much
easier to isolate an issue in APR, it's likely far too complex
otherwise.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Strange APR/native behaviour

[Remy Maucherat]

On Tue, 2013-03-12 at 00:25 +, Mark Thomas wrote:
> I have been tracking down a problem with the Autobahn test suite and
> APR/native connector when using SSL (all is fine with non-SSL).
> 
> In the test Autobahn sends a 16MB frame to the server which the server
> echos back to the client.
> 
> The problem I am seeing is with a non-blocking write in the
> AprServletOutputStream [1].
> 
> If a write returns EAGAIN (line 97) the socket is added to the poller
> for write notifications. The poller immediately returns the socket as
> ready for write. Another write is attempted that returns EAGAIN and the
> code enters an infinite loop with no more data ever written to the socket.
> 
> If I add a delay around line 46 that slows the rate of writing down,
> EAGAIN is never returned and the test completes successfully.
> 
> I assume I am doing something wrong. Pointers appreciated.

So I don't know precisely, but for non blocking, you're not doing the
same thing I'm doing (which went through stress tests successfully on
some platforms - but not on OS X, the OS is too cool for using it for
this kind of dirty work, I presume).

Here are some differences (that could be attempted):
- to set non blocking, I don't use optSet with APR_SO_NONBLOCK (it did
weird things at that time, not 100% sure now), but
Socket.timeoutSet(socket, 0) since Mladen told me that is the proper way
to set non blocking mode
- to do the actual send of the bytes, I use sendibb (which is sendib
with an internal byte buffer), I think it's not the same as the regular
send since it doesn't retry (says the javadoc, not sure if it can be
fully trusted ;) )
- I check if it needs to be put in the poller using the number of bytes
wrtten (if 0, it goes to the poller, if not, write again if there's more
data), not some status like EAGAIN (IMO that's riskier, since the exact
bahavior of statuses are sometimes platform specific)
- to exit non blocking mode, I set the previous timeout value and use
sendbb (again, with the internal byte buffer)
- I don't use syncs on IO, the design of the async in Servlet 3.1 is
supposed to allow avoiding that (of course, if the user does concurrent
writes without a lock on his own, it will bomb, but IMO, it should)

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: URIs, %nn decoding and error handling

[Remy Maucherat]

On Fri, 2013-03-01 at 20:36 +, Mark Thomas wrote:
> I expect to have a similar discussion about request bodies once URIs are 
> resolved where I have essentially the same view - a decoding error 
> should lead to a request failure.
> 
> Thoughts?

It may not be useful. UTF-8 is THE most used encoding. If the decoder is
still full of bugs, it means the other encoders/decoders have even more
bugs. So the only reasonable statement is that you would like to have
"perfect" UTF-8 decoding, and so you would use your own decoder in
B2CConverter, just for that encoding. Ok.

About endOfInput, I wouldn't use it. The only place where it is somewhat
useful is the URI conversion, which can check the underflow flag and
throw an exception. Especially if you also want to have "perfect" body
decoding, you'll have to use that flag and throw your exception since it
won't be able to use endOfInput. I don't bother with either personally,
but it's the reason for the existence of the flag.

The main purpose of the new B2C and C2B code is to have better handling
of non blocking (not required in Servlet 3.1, in the end; at least for
now), and that's about it. Since they also look better, save memory and
are symmetrical, I thought it would be a good idea to add them. I didn't
expect to cause so much trouble, ;)

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Checkstyle errors in storeconfig in trunk

[Remy Maucherat]

On Sat, 2013-02-09 at 05:19 +0400, Konstantin Kolinko wrote:
> 2013/2/8 Konstantin Kolinko :
> > Hi!
> >
> > FYI, there are a lot of checkstyle errors in o.a.c.storeconfig package,
> >
> > a) tabs in server-registry.xml
> > b) a lot of trailing whitespace
> 
> Fixed.

Thanks !

> Further notices:
> 1. In a lot of places the code uses name "childs" instead of "children".
> 
> E.g. childs="true" in server-registry.xml
> E.g. storeChilds(..) method in StoreFactoryBase class

This probably didn't change from the initial revision of the component.
I guess I didn't event notice it (ahah). Is it worth fixing ? (probably)

> 2. Javadoc for StoreLoader documents XML format for a registry file.
> 
> What I see there is not what I see in server-registry.xml file in the
> storeconfig package.
> 
> E.g. documented
>  ,
> actual
>  

I suppose the XML was a bit simplified after the doc was written.

> 3. Checkstyle now shows a number (27) of "disallowed import" warnings.
> Those are imports from "o.a.catalina.tribes" and "o.a.catalina.ha".
> 
> I think it just means that this component depends on those,
> and Checkstyle rules needs adjustment here.

Storeconfig needs that dependency (obvious), so the warning should be
silenced or ignored.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1443891 - /tomcat/trunk/java/org/apache/catalina/storeconfig/server-registry.xml

[Remy Maucherat]

On Fri, 2013-02-08 at 21:19 +0400, Konstantin Kolinko wrote:
> 2013/2/8  :
> > Author: kfujino
> > Date: Fri Feb  8 08:50:24 2013
> > New Revision: 1443891
> >
> > URL: http://svn.apache.org/r1443891
> > Log:
> > Improve ContextSF description.
> > Remove unused attributes engineName and saveConfig.
> > Add effectiveMajorVersion and effectiveMinorVersion to TransientAttribute.
> >
> > Modified:
> > tomcat/trunk/java/org/apache/catalina/storeconfig/server-registry.xml
> >
> 
> At the top of this registry file the following is written:
> 
> 
> 
> Though I do not know whether this "version" attribute matters.

I think its main use is, when storeconfig is an external component, to
know which Tomcat version it supports. I'll verify it and drop it if
possible.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1443872 - /tomcat/trunk/java/org/apache/catalina/storeconfig/StoreConfigLifecycleListener.java

[Remy Maucherat]

On Fri, 2013-02-08 at 08:24 +, kfuj...@apache.org wrote:
> Author: kfujino
> Date: Fri Feb  8 08:24:36 2013
> New Revision: 1443872
> 
> URL: http://svn.apache.org/r1443872
> Log:
> Don't use a hard-coded domain name.

Actually, I'm not sure this is a good plan. This was most certainly
hardcoded on purpose, so that the mbean is always available at a known
location, and from where it could handle the full container (with
multiple servers/domains ?). Don't know exactly what Peter had in mind
though.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Proposal] Resurrecting storeconfig

[Remy Maucherat]

On Tue, 2013-02-05 at 19:27 +0900, Keiichi Fujino wrote:
> Hi.
> 
> I do not understand about StoreConfig well, but I have a question.
> 
> As long as I read the code (r1442161), I think that storeconfig() seem
> to trigger a redeployment of Web applications.
> For example, new context.xml will be created when
> testApp/META-INF/context.xml is stored.
> And redeployment of this new context.xml will be done by HostConfig.
> Is this a design ?
> I think better that storeconfig () does not trigger a redeployment of
> the Web application.

Yes, storeconfig will saved these (settings could have been changed).
Then the deployer sees the updated descriptor, and it redeploys the
webapp.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Proposal] Resurrecting storeconfig

[Remy Maucherat]

On Fri, 2012-12-14 at 17:26 +, Mark Thomas wrote:
> > One issue I'm wondering about is the build system. After all that time,
> > I've starting using Maven instead of Ant (unbelievable, I know ...), and
> > while I am fine continuing using existing Ant build systems, I find
> > adding ones to newer components quite useless.
> 
> It shouldn't be too hard to add another JAR to the existing Ant build.
> Once the code is in place, I'm happy to take a look.

I have ported it to trunk, where it builds as
lib/catalina-storeconfig.jar. Should I commit it ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat Native 1.1.26

[Remy Maucherat]

On Mon, 2013-01-28 at 12:33 +0100, Rainer Jung wrote:
> On 25.01.2013 17:01, jean-frederic clere wrote:
> > Version 1.1.26 is bug fixing release.
> > The proposed release artefacts can be found at [1],
> > and the build was done using tag [2].
> > 
> > The VOTE will remain open for at least 48 hours.
> > 
> > The Apache Tomcat Native 1.1.26 is
> >  [X] Stable, go ahead and release
> >  [ ] Broken because of ...
> 
> +1 to release

+1 as well.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: NIO in char IO

[Remy Maucherat]

On Wed, 2013-01-23 at 18:55 +, Mark Thomas wrote:
> On 23/01/2013 16:44, Remy Maucherat wrote:
> > Hi,
> > 
> > I have ported a refactoring of character encoding (and decoding) to
> > trunk, using NIO rather than the creative hacks that are used. It makes
> > the IO nice and symmetrical, but I haven't specifically tested any
> > performance (I couldn't stand the old style, so it had to go regardless
> > of the consequences).
> > 
> > See here for what it looks like:
> > http://anonsvn.jboss.org/repos/jbossweb/branches/7.2.x/src/main/java/org/apache/tomcat/util/buf/C2BConverter.java
> > 
> > To use it, there's a number of minor changes scattered in the IO and URI
> > encoding. Should I commit it ?
> 
> I only have a few minor quibbles:
> - The @author tags should be removed in the ASF version
> - s/CodingErrorAction.REPLACE/CodingErrorAction.REPORT/

It's not exactly what I will commit anyway, it's just to give an idea.

About the CodingErrorAction on unmappable, the current (and right)
behavior is (somehow) to replace with '?'. Even on malformed characters,
some people want to replace rather than get an exception (that's
normally also the current behavior) because the data output might come
from user input or someplace similar where it could have funny encoding
(so I was told). Report is the default for both, so there's nothing to
do in that case.

Maybe there could be two configuration options as there's now an
opportunity to fine tune the behavior (there are 3 values: ignore,
report - the default - and replace).

> Overall I like the simplicity. It should be much easier for folks to
> follow (and if it makes NIO easier all the better).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

NIO in char IO

[Remy Maucherat]

Hi,

I have ported a refactoring of character encoding (and decoding) to
trunk, using NIO rather than the creative hacks that are used. It makes
the IO nice and symmetrical, but I haven't specifically tested any
performance (I couldn't stand the old style, so it had to go regardless
of the consequences).

See here for what it looks like:
http://anonsvn.jboss.org/repos/jbossweb/branches/7.2.x/src/main/java/org/apache/tomcat/util/buf/C2BConverter.java

To use it, there's a number of minor changes scattered in the IO and URI
encoding. Should I commit it ?

Note: Although this is not required by Servlet 3.1 [for now], it was
useful to do async IO with the Servlet reader/writer, since it is far
preferable to have good visibility on the buffering (essentially, it
only uses the main byte buffer of the Input/OutputBuffer).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1436814 - /tomcat/trunk/webapps/docs/rewrite.xml

[Remy Maucherat]

On Tue, 2013-01-22 at 09:19 +, ma...@apache.org wrote:
> Author: markt
> Date: Tue Jan 22 09:19:26 2013
> New Revision: 1436814
> 
> URL: http://svn.apache.org/viewvc?rev=1436814&view=rev
> Log:
> Add license
> tabs -> spaces
> remove trailing whitespace

Thanks for all the beautifying.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Rewrite functionality for 8

[Remy Maucherat]

On Mon, 2013-01-21 at 15:52 +0100, Henri Gomez wrote:
> mod_rewrite is definitvly HTTPd Swiss Knife and having it in Tomcat is
> definitivly a good news.
> 
> This valve is for Tomcat 8 and higher or could it be used with Tomcat 7 ?

It will probably not build as is but as with almost everything, it can
be backported.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1433976 - in /tomcat/trunk/java/org/apache: coyote/ajp/AjpAprProtocol.java coyote/http11/Http11AprProtocol.java tomcat/util/net/AprEndpoint.java tomcat/util/net/res/LocalStrings.prope

[Remy Maucherat]

On Wed, 2013-01-16 at 15:14 +, ma...@apache.org wrote:
> This is untested (I don't have an OSX build of the native lib handy right 
> now). I'll test later today.

I'm not sure native on OS X is 100% stable, for whatever reason (due to
apparent concurrency issues with the poller once read + write polling is
used). It could depend on the APR / Tomcat Native version used and be
fixed now, but certainly there were issues on OS X that didn't occur on
Linux (or Windows, ...) at the time. I didn't test or investigate
myself, so I don't know more than that, good luck with the testing.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: APR, WebSocket and Servlet 3.1 NIO refactoring

[Remy Maucherat]

On Wed, 2013-01-16 at 12:08 +, Mark Thomas wrote:
> > It is not really a bug: only the newer Windows (Vista+) have efficient
> > polling. With previous versions, small pollsets have to be used because
> > (apparently) it can only poll over 64 sockets at a time. If the size is
> > over 1000, there is a big performance impact. It is supposed to be
> > handled well in APR (using the new APIs if available).
> > 
> > Source: Mladen some time ago. Hopefully, I understood everything
> > correctly ;)
> 
> It looks like lifting your new Poller implementation (and associated
> supporting classes) will be the quickest way forward at this point. Am I
> correct in assuming you are happy for me to do that?

Yes, I think you should use that poller code (at least a little bit),
it's rather tricky.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: APR, WebSocket and Servlet 3.1 NIO refactoring

[Remy Maucherat]

On Wed, 2013-01-16 at 11:43 +, Mark Thomas wrote:
> > Using multiple pollsets is only needed on some platforms (Windows ...),
> > and it is possible it is not supposed to be mandatory now (Windows
> > should be able to handle large pollsets now). So if you accept to drop
> > support for running production on older things (ex: XP), it can be
> > simplified. To be confirmed though ;)
> 
> Tempting...
> 
> XP is still my primary development environment and only this week I
> found the solution to the hardware compatibility issue that was stopping
> me upgrading.
> 
> If XP has an issue (which doesn't surprise me at all) then I suspect
> Server 2003 will have the same problem. That is supported until (at
> least) July 2015 so I think dropping support (as much as I like deleting
> code) is a little premature.

It is not really a bug: only the newer Windows (Vista+) have efficient
polling. With previous versions, small pollsets have to be used because
(apparently) it can only poll over 64 sockets at a time. If the size is
over 1000, there is a big performance impact. It is supposed to be
handled well in APR (using the new APIs if available).

Source: Mladen some time ago. Hopefully, I understood everything
correctly ;)

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: APR, WebSocket and Servlet 3.1 NIO refactoring

[Remy Maucherat]

On Wed, 2013-01-16 at 09:35 +, Mark Thomas wrote:
> That would be really nice. What I'd need is this:
> 
> int removeFromPollset(long socket)
> 
> where the return value is either -ve for an error code or +ve for the
> current flags.
> 
> Looking at the code, by the time I have finished the other changes the
> change above would be a nice to have but not essential.
> 
> One of the changes that will help (Remy already did this in his fork) is
> to move from:
> 1 pollset <-> 1 poller, 1 endpoint <-> multiple pollers
> to:
> 1 endpoint <-> 1 poller, multiple pollsets <-> 1 poller
> 
> This is next on my todo list.

Using multiple pollsets is only needed on some platforms (Windows ...),
and it is possible it is not supposed to be mandatory now (Windows
should be able to handle large pollsets now). So if you accept to drop
support for running production on older things (ex: XP), it can be
simplified. To be confirmed though ;)

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: APR, WebSocket and Servlet 3.1 NIO refactoring

[Remy Maucherat]

On Wed, 2013-01-16 at 07:50 +0100, Mladen Turk wrote:
> On 01/15/2013 02:29 PM, Mark Thomas wrote:
> > Hi,
> >
> > 3. Currently, we have no record of which Poller a socket is registered
> > with. This makes 2) more expensive as we have to iterate through the
> > Pollers to find the socket. Tracking the current poller used by a socket
> > would make 2) a cheaper operation.
> 
> Think this can be done with relative ease.
> I recently made some changes to native pollset performance
> (removing multiple linear scans for sockets if they are in the pollset)
> which can reference the pollset with socket.
> 
> In theory this allows to remove the socket from 'any' pollset which
> means that you can remove the socket from pollset without knowing to
> which one it belongs.
> 
> If there is a need for reconfigure (different signaling events)
> we can add an extra API call that would allow that, without the need
> to know for which pollset this is.

Yes, remove [and add as well, but hopefully this was never a big issue]
performance is essential, because write events mean more events, and
flags also need to be updated. So a lot more operations overall.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: APR, WebSocket and Servlet 3.1 NIO refactoring

[Remy Maucherat]

On Tue, 2013-01-15 at 19:26 +, Mark Thomas wrote:
> >I had to solve each of these issues in the web container of JBoss.
> >Although this is not going to be quite 100% compatible with Tomcat, it
> >is very similar.
> >
> >I recommend looking at the branch that is in AS 7 trunk:
> >http://anonsvn.jboss.org/repos/jbossweb/branches/7.2.x/
> 
> Thanks. The more I look into this the more strangeness I find. I'll keep
> the above in mind if I need some pointers.

Ok. With APR, dealing with the poller is not very forgiving, so I think
you should use that, it is well tested too (plus the license is ASL
now).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: APR, WebSocket and Servlet 3.1 NIO refactoring

[Remy Maucherat]

On Tue, 2013-01-15 at 13:29 +, Mark Thomas wrote:
> Hi,
> 
> I think I am going to need to refactor the APR Poller code. Before I get
> to far down that road I wanted to get a sanity check from those that
> understand the APR/native connector better than I do.
> 
> The main problem:
> - I need to be able to update the flags for a socket current in the
> poller. For example, adding FLAGS_WRITE to a socket that currently has
> FLAGS_READ
> 
> Side issues:
> - APR connections don't track number of HTTP keep-alives left (it gets
> reset every time the socket goes back to the Poller)
> - Currently we have two completely separate sets of Pollers. Once for
> Comet and one for non-Comet.
> 
> The reasoning for the refactoring:
> 
> 1. Sockets should only be added to a pollset once.
> 2. Because of 1) to update the flags the socket needs to be removed from
> the pollset and re-added with the new flags.
> 3. Currently, we have no record of which Poller a socket is registered
> with. This makes 2) more expensive as we have to iterate through the
> Pollers to find the socket. Tracking the current poller used by a socket
> would make 2) a cheaper operation.
> 4. Implementing 3) requires maintaining a mapping from socket to
> SocketWrapper (like KeyAttachment does in NIO)
> 5. A simple Map of Socket->SocketWrapper should give us what we need.

I had to solve each of these issues in the web container of JBoss.
Although this is not going to be quite 100% compatible with Tomcat, it
is very similar.

I recommend looking at the branch that is in AS 7 trunk:
http://anonsvn.jboss.org/repos/jbossweb/branches/7.2.x/

> In addition to enabling me to continue with the Servlet 3.1 NIO work,
> the other advantages to the proposed refactoring are:
> - Will be able to eliminate the CometPollers since the SocketWrapper
> knows if a request is Comet or not.
> - Proper tracking of HTTP keep-alive requests left per connection.
> 
> If anyone can see a good reason not to start down this path, please
> speak up.

With APR, I would keep a separate poller for events (called comet in
Tomcat) and keepalive, the code is rather different.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Rewrite functionality for 8

[Remy Maucherat]

On Fri, 2013-01-11 at 18:34 +0100, Rainer Jung wrote:
> I only had a look at the code and didn't play with it yet. I'm
> positively impressed how complete w.r.t. mod_rewrite compatibility it
> looks and personally I think it is nice and useful.

Thanks !

> One question that came to my mind and which I did not yet try to find
> the answer myself is the merging behavior of the rules if the valve is
> configured at host and context level.

I didn't really think about this scenario. There's no direct interaction
between the two valves. For the current implementation, if the valve in
the context has its config file in /WEB-INF/rewrite.properties, it will
use that. If not, it will try to use
conf/Catalina/localhost/rewrite.properties (the valve defined on the
host will only look there). But there's no rule inheritance or something
like it.

The two rewrite valves will do their processing only once (the valve has
a thread local boolean to avoid rewriting more than once per request).
If both valves do a rewrite, here's the processing (assuming the mapping
of the host and context doesn't change, since the request is pretty much
allowed to bounce between hosts and contexts as long as rewriting occurs
in each host or context):
adapter (mapping 1) -> rewrite in host -> adapter (mapping 2) -> rewrite
in context -> adapter (mapping 3) -> webapp

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Rewrite functionality for 8

[Remy Maucherat]

On Wed, 2013-01-09 at 13:16 -0500, Christopher Schultz wrote:
> I haven't looked at the code but my first reaction was "why not use
> url-rewrite?" When you say that it can re-start request processing, you
> mean that you can essentially perform internal rewrites/forwards/etc.
> without having to use the request dispatcher? Certainly reducing stack
> size is not a bad idea and should improve performance.

It may improve performance, but most importantly the application's state
is untouched. It will not see any of the original request in its
filters, only the modified one, etc.

> The fact that it is mostly compatible with mod_rewrite configuration
> syntax is definitely a plus, though url-rewrite 4 can read
> mod_rewrite-style configuration files, too.
> 
> Finally, there is the spec-versus-implementation issue. It's great that
> Tomcat could provide this kind of capability, but since it is
> out-of-spec we might be doing a disservice to our users. I know I'm
> always irritated when someone posts to the users' list that they are
> switching from JBoss/Sun/Jetty/Whatever and Tomcat doesn't mirror some
> out-of-spec capability and they are all mad about it. That's what I like
> about url-rewrite: you make it a part of your webapp and it should work
> everywhere.

The valve works at the vhost level as well (as I mentioned in my
previous email), there were [minor] user requests for "creative" vhost
mapping.

So it should be able to do a lot of things that are quite complex to do
otherwise, and is generally useful for customer support [since it can do
anything except proxying].

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Rewrite functionality for 8

[Remy Maucherat]

Hi,

I ported a valve providing mod_rewrite functionality (most of it) for
Tomcat "8", and committed it in the sandbox. This could be easily placed
in the main repository, where it would provide an additional item in the
"new features" department for this major release.

I have a documentation page for it that could be included. The basics is
that it uses a rewrite.properties that has the same contents as the
configuration for mod_rewrite. The rewrite.properties is placed in the
host config folder if the valve is declared in a Host, or in WEB-INF in
the webapp if declared in a Context.

The main differences with mod_rewrite are:
- (the big one) no proxy flag
- no SSL attributes
- less file related flags available
- allows virtual host rewriting using a host flag (it replaces the host
header instead of the URL and maps again)
Point 2 and 3 are probably relatively easy to fix, while obviously a
proxy is a more involving endeavor.

There are rewrite solutions out there already, but this one does not use
complex tricks (because it can simply start over request processing
instead of doing more complex request dispatching, which also impacts
the Servlet state), and is mod_rewrite compatible.

Comments ? Is it nice or useless ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Proposal] Resurrecting storeconfig

[Remy Maucherat]

On Fri, 2012-12-14 at 17:26 +, Mark Thomas wrote:
> > The proposal would be to move "storeconfig7/trunk" from the sandbox to
> > "modules/storeconfig" in the Tomcat 7 branch [a port to trunk, aka
> > Tomcat "8", would be coming shortly, since I believe its container API
> > would now start to be more stable].
> 
> :)
> Merging Engine and Service are still on the Tomcat 8 TODO list but I'm
> increasingly coming to the view that it isn't worth doing. It would
> break lots of existing stuff and the benefit of the merge is marginal.
> The other largish looking changes (e.g. web.xml parsing) shouldn't
> impact much / at all on StoreConfig.
> 
> How far away is the trunk version?

I didn't try porting or testing with trunk yet, but I don't expect it to
be too difficult if the big changes were deferred. I thought they had
already been done in trunk actually, I should have looked at the code I
guess.

> > I don't recall Tomcat 6 having
> > modules, so I don't see where storeconfig6 would live there, and as a
> > result I propose leaving it in the sandbox.
> 
> We could create a modules in tc6.0.x/trunk
> 
> One of your changes that I have really come to appreciate over the years
> is the single source tree. What was your reasoning for adding it in
> modules rather than the main source tree?

There's a module for the JDBC pool in Tomcat 7, so I figured storeconfig
could be a new module there, it did sound logical. But a JDBC pool is
certainly more independent of Tomcat than storeconfig. If officially
bringing it back to Tomcat 6 as well, maybe it could be in the main tree
since creating a new modules location just for it is not going to be so
nice.

Having zillions of source trees is quite trendy these days, with Maven
to glue all the pieces together. I find it harder to work with it
though, and using Ant it is just quite crazy. So I guess there are
benefits and issues.

So either option is fine with me, it could be merged in the main tree,
or it could be a module. Either way, it could create its own jar.

> > One issue I'm wondering about is the build system. After all that time,
> > I've starting using Maven instead of Ant (unbelievable, I know ...), and
> > while I am fine continuing using existing Ant build systems, I find
> > adding ones to newer components quite useless.
> 
> It shouldn't be too hard to add another JAR to the existing Ant build.
> Once the code is in place, I'm happy to take a look.

Yes, it should not be too hard.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Proposal] Resurrecting storeconfig

[Remy Maucherat]

Hi,

I would be willing to start maintaining again storeconfig, along with
Jean-Frédéric. So after a hiatus, we would be able to bring back this
functionality which allows tweaking the configuration (through JMX in
particular) and then saving it to server.xml and context.xml files to
make changes survive a restart. On the downside, storeconfig in Tomcat
will always remain an introspection based system prone to (very rare,
hopefully) failures and some unhandled special cases, a artifact of
Tomcat's rather freeform configuration files.

The proposal would be to move "storeconfig7/trunk" from the sandbox to
"modules/storeconfig" in the Tomcat 7 branch [a port to trunk, aka
Tomcat "8", would be coming shortly, since I believe its container API
would now start to be more stable]. I don't recall Tomcat 6 having
modules, so I don't see where storeconfig6 would live there, and as a
result I propose leaving it in the sandbox.

One issue I'm wondering about is the build system. After all that time,
I've starting using Maven instead of Ant (unbelievable, I know ...), and
while I am fine continuing using existing Ant build systems, I find
adding ones to newer components quite useless.

Comments ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.36

[Remy Maucherat]

On Tue, 2012-10-16 at 10:52 +0200, jean-frederic clere wrote:
> The candidates binaries are available here:
> http://people.apache.org/~jfclere/tomcat-6/v6.0.36/
> 
> According to the release process, the 6.0.36 build corresponding to the
> tag TOMCAT_6_0_36 is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [X] Stable

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Resources - Custom URL scheme for unified access

[Remy Maucherat]

On Tue, 2012-10-09 at 22:19 +0100, Mark Thomas wrote:
> If we do go this route I'd like to change the scheme from "jndi://" to
> "tomcat://". This is for several reasons:
> - I believe there was a complaint that "jndi://" clashed with another
>   component.
> - It makes clear the old and the new are very different and not
>   compatible.

Not sure if it clashed with something, but the main reason it was
"jndi://" is because the API used was JNDI. So use something else,
"tomcat://" sounds good.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Resources - Is DirContext the right basis for the API?

[Remy Maucherat]

On Thu, 2012-09-27 at 07:34 -0700, Costin Manolache wrote:
> One use for a resource API is if it provides different backends - like
> Hadoop filesystem abstraction
> does. Than you could serve from hdfs/db/etc, and someone could use the same
> api in deploy tools
>  or general programs.
> One of the unrealized benefits with JNDI was that it may provide many
> backends - LDAP, DB, etc -
> that would be directly usable in tomcat.

Yes, you convinced me to bother with JNDI in order to have a standard
API that others could use if they wanted to integrate. I used it in
Slide, but that was it, so it wasn't useful in the end. Of course, we
had no real idea to know that at the time, and it is possibly because we
didn't bother documenting/advertising it much.

> If the new resources can be implemented as a self-contained dependency,
> i.e. don't require
> the entire tomcat - someone could use them in other apps.
> 
> BTW - how does it compare with hadoop FS ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Recent performance tweaks in trunk

[Remy Maucherat]

On Sun, 2012-09-23 at 12:35 +0100, Mark Thomas wrote:
> ab -c 4 -k -n 100 http://localhost:8080/test-1k.txt

The concurrency of the test is very low, there will be only 4 threads
used with that test, which means decent sync performance.

Although with NIO the executor count can remain lower than on java.io,
many webapps will still need a significant amount of them, so in
practice it is simply not possible to have any syncing (for example,
there's one needed sync in the APR connector for adding sockets back to
the poller, and it hurts a lot - essentially, the connector works well
enough only with a "small" thread pool).

So adding caches like this is likely not a good idea.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: non blocking API

[Remy Maucherat]

On Thu, 2012-06-28 at 16:59 -0600, Filip Hanik (mailing lists) wrote:
> I posted some feedback to the expert group:
> 
> http://java.net/projects/servlet-spec/lists/users/archive/2012-06/message/15

You can find all the discussions about the API in the archive, which
hopefully explain nearly all of the items:
http://java.net/projects/servlet-spec/lists/jsr340-experts/archive
(summary: reuse of existing API, efficiency, user simplicity)

As for the flags without listeners, it is the regular blocking IO, no
polling occurs (so ready + canWrite are false; in theory ready could be
true if there's something in the servlet buffer). The flag definition is
actually rather precise already (returns false if it may block), but
there's additional wording which will be added later.

So, sorry about the "bad" result, but that's the least worst the EG
could come up with so far, after considering all API styles (I believe).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: SPDY support

[Remy Maucherat]

On Thu, 2012-02-02 at 12:28 +, Pid wrote:
> > Of course, I'm even less sure about websockets since it's kind of a mess.
> 
> I'd say it was the other way round.  WebSockets finalised before Xmas,
> and there's lots of interest from various communities to judge from the BZ.

Websocrap is a bad transport. If it wasn't, we'd know if it was message
or stream based, and it would be message based.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: SPDY support

[Remy Maucherat]

On Wed, 2012-02-01 at 13:54 -0800, Costin Manolache wrote:
> Hi,
> 
> Some initial patch for SPDY - using the NPN SSL extension, as required by
> chrome/firefox.
> 
> I used github so it's easy to add comments or test:
> 
> https://github.com/costinm/tomcat/commit/e97def3314216c083cc4b68ad9731e5a94b2af28
> 
> Basic 'hello world' works in both jio and apr, looking for opinions on the
> integration with tomcat connectors.
> Please let me know :-)

Ok, I think your "light protocol" concept to group any "upgraded"
connections is appropriate.

Not sure about spdy though, is anyone using it ? Of course, I'm even
less sure about websockets since it's kind of a mess.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1140463 - in /tomcat/trunk/java/org/apache/catalina: connector/Request.java ssi/SSIServletExternalResolver.java util/Base64.java

[Remy Maucherat]

On Tue, 2011-06-28 at 07:22 +, ma...@apache.org wrote:
> Author: markt
> Date: Tue Jun 28 07:22:28 2011
> New Revision: 1140463
> 
> URL: http://svn.apache.org/viewvc?rev=1140463&view=rev
> Log:
> Fix the remaining instances of new String(byte[] b, String enc) that can be 
> fixed

It is possible this fix makes StringCache less useful.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1132367 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11AprProcessor.java webapps/docs/changelog.xml

[Remy Maucherat]

On Mon, 2011-06-06 at 19:15 +0100, Mark Thomas wrote:
> Doh. Got it. We do need to modify the length to handle range requests,
> but not like that.

What's the issue exactly ? When actually sending data, "pos" is set to
"start" and the length is used as the usual "end - pos".

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1132367 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11AprProcessor.java webapps/docs/changelog.xml

[Remy Maucherat]

On Sun, 2011-06-05 at 10:21 +, ma...@apache.org wrote:
> Author: markt
> Date: Sun Jun  5 10:21:25 2011
> New Revision: 1132367
> 
> URL: http://svn.apache.org/viewvc?rev=1132367&view=rev
> Log:
> Correctly handle range requests when using sendfile and the APR/native HTTP 
> connector.
> -"org.apache.tomcat.sendfile.end")).longValue();
> +"org.apache.tomcat.sendfile.end")).longValue() - 
> sendfileData.pos;

I don't understand, the code reads:
sendfileData = new AprEndpoint.SendfileData();
sendfileData.fileName = fileName;
sendfileData.start = ((Long) request.getAttribute(
"org.apache.tomcat.sendfile.start")).longValue();
sendfileData.end = ((Long) request.getAttribute(
"org.apache.tomcat.sendfile.end")).longValue() - sendfileData.pos; 

So how can sendfileData.pos not be 0 here ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1094069 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/manager/ java/org/apache/catalina/session/ webapps/docs/

[Remy Maucherat]

On Sat, 2011-04-16 at 22:25 +, ma...@apache.org wrote:
> Author: markt
> Date: Sat Apr 16 22:25:28 2011
> New Revision: 1094069
> 
> URL: http://svn.apache.org/viewvc?rev=1094069&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51042
> Don't trigger session creation listeners when changing the session ID during 
> authentication.

But the listeners have to be aware that the id changed.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.32

[Remy Maucherat]

On Wed, 2011-02-02 at 20:37 +0100, jean-frederic clere wrote:
> The candidates binaries are available here:
> http://people.apache.org/~jfclere/tomcat-6/v6.0.32/
> 
> According to the release process, the 6.0.32 build corresponding to the
> tag TOMCAT_6_0_32 is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [X] Stable

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1061442 - in /tomcat/trunk/java/org/apache/catalina/connector: LocalStrings.properties Request.java

[Remy Maucherat]

On Thu, 2011-01-20 at 18:34 +, ma...@apache.org wrote:
> Author: markt
> Date: Thu Jan 20 18:34:18 2011
> New Revision: 1061442
> 
> URL: http://svn.apache.org/viewvc?rev=1061442&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50620
> Exceptions calling session.endAccess should not prevent recycle() from 
> completing normally

How can endAccess throw an exception ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Remove o.a.catlina.InstanceListener

[Remy Maucherat]

On Fri, 2011-01-07 at 15:18 +0300, Konstantin Kolinko wrote:
> We indeed do not have our own classes that implement InstanceListener,
> but if you search for o.a.c.InstanceEvent, it is used in a plenty of places
> (to implement this feature actually).
> 
> So it is not just throwing away classes, it also removal of many lines of 
> code.
> 
> Searching the web, it is mentioned e.g. here:
> http://community.jboss.org/message/288150?tstart=0
> 
> See also
> http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_1_0_GA/tomcat/src/main/org/jboss/web/tomcat/security/RunAsListener.java
> 
> My opinion on this proposal is "-1".

The web container that is used there is not fully compatible with Tomcat
already, so you can remove InstanceListener in Tomcat without breaking
AS.

However, unless there's a comparable hook somewhere, removing this is
probably not a good idea, valves and filters are not exactly the same
thing.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/

[Remy Maucherat]

On Thu, 2010-11-25 at 16:33 +, Mark Thomas wrote:
> I wouldn't call it bad. It doesn't do any harm (apart from adding a very
> small amount of overhead), and it would help if the random source
> selected ended up not being that random.
> 
> I thought the trade-off of protection against bad choices of random
> sources was worth the minimal overhead added. I'm not against removing
> it entirely, if there is consensus to do so.

MD5 is now known as a bad hash (it was fine at the time the code was
written), so does it actually improve anything ?

Also, isn't SecureRandom always available now ? This is 10+ years old
code, probably.

> For SecureRandom, yes. I did test this locally and it achieves
> thread-safety by using an internal sync and it did create a significant
> bottleneck. That is why I went the parallel route. Reading from a stream
> has a similar sync so again that is why I went the parallel route.

Ok. The internal lock is a much smaller sync than the old sync block, so
it would be a bit better. It is possible it is noticeable, though. The
question is if this yields a good enough session creation rate.

> How about this as an approach to reduce the complexity:
> 1. Remove the MD5 code (optional)
> 2. Default to /dev/urandom then SecureRandom. Don't fall back to Random.
> 3. Provide a class that implements Random that reads data from a file
> 4. If randomFile is specified, use the the class from 3 as the Random source
> 
> That should reduce the current 3 Queues to one. I doubt it will improve
> performance much but it should make the code clearer.
> 
> Thoughts?

I don't know what the best solution is. /dev/urandom could also only be
used as seed only to a SecureRandom, this is more Javaish.
So about the MD5, I don't think it is useful anymore.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/

[Remy Maucherat]

On Thu, 2010-11-18 at 19:59 +, ma...@apache.org wrote:
> Author: markt
> Date: Thu Nov 18 19:59:11 2010
> New Revision: 1036595
> 
> URL: http://svn.apache.org/viewvc?rev=1036595&view=rev
> Log:
> Fix expiration statistics broken by r1036281
> Add session creation and expiration rate statistics based on the 100 most 
> recently created/expired sessions
> Modify average session alive time to also use 100 most recently expired 
> sessions
> Update benchmarks - new statistics add overhead but not significant in 
> overall processing chain

But going back to the original optimization work, I still don't quite
understand. As Tim pointed out, the MD5 hash is probably bad, and
SecureRandom is already internally thread safe. So the simplest
refactoring (remove the hash and the synchroinized block) was not
tested. Is it really a big enough bottleneck which would need the more
complex plumbing to parallelize ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1036150 - /tomcat/trunk/webapps/docs/changelog.xml

[Remy Maucherat]

On Wed, 2010-11-17 at 18:06 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Nov 17 18:06:20 2010
> New Revision: 1036150
> 
> URL: http://svn.apache.org/viewvc?rev=1036150&view=rev
> Log:
> Add recent performance improvements to changelog

Ok.

So we have two queues that can essentially grow up to the thread count,
right ?. You have chosen to not use thread locals though (they would
most likely perform better, at the cost of more memory). Any testing ?

Another question: is it safe on all platforms to concurrently read
uramdom from a single process ? I suppose it is probably safe, but do we
know for sure ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1035699 - in /tomcat/trunk: java/org/apache/catalina/session/ManagerBase.java test/org/apache/catalina/session/Benchmarks.java

[Remy Maucherat]

On Tue, 2010-11-16 at 17:13 +, ma...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1035699&view=rev
> Log:
> Session manager performance
> Narrow sync - few % improvement
> - *  1 thread  -  2,422ms
> - *  2 threads -  5,047ms
> - *  4 threads - 13,188ms
> - * 16 threads - 54,422ms
> + *  1 thread  -  ~2,400ms
> + *  2 threads -  ~4,700ms
> + *  4 threads - ~12,600ms
> + * 16 threads - ~53,700ms

Hmm, not very significant.

I knew about the relatively low session creation performance, but unless
there's a secure way to remove the sync on getRandomBytes, there's no
way to improve this. Having multiple (= thread local) random sources is
probably not a good idea.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PATCH] Parallel deployment

[Remy Maucherat]

On Mon, 2010-11-08 at 18:26 +0100, Rainer Jung wrote:
> On 08.11.2010 18:05, Remy Maucherat wrote:
> > I'll up that to -1, with another concern I've just thought about: if
> > using a session id path which includes more than one webapp, the version
> > numbers will have problems matching between the two webapps.
> 
> You mean situations like portals / emptysessionpath?

It is replaced by direct session path configuration in Servlet 3, but
the problem is the same as with the old portal workaround from previous
versions.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PATCH] Parallel deployment

[Remy Maucherat]

On Mon, 2010-11-08 at 15:46 +, Mark Thomas wrote:
> I did consider that approach but rejected it for a couple of reasons:
> - Mapper needs to be manager aware - it isn't currently

Add a one method interface to be able to perform a session lookup.

> - Performance

Likely, having to do String manipulation/parsing is much worse than a
map lookup.

> Now the clean-up is in place and we can focus on the actual changes I'll
> probably go back and take another look at this option. It is almost
> certain I didn't fully explore all the possible ways of doing this.
> 
> > I don't agree with adding a version number/id to the session id, or
> > changing its format, this will create legacy issues, as we can see right
> > now.
> 
> An understandable concern.

I'll up that to -1, with another concern I've just thought about: if
using a session id path which includes more than one webapp, the version
numbers will have problems matching between the two webapps.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PATCH] Parallel deployment

[Remy Maucherat]

On Mon, 2010-11-08 at 14:31 +, Mark Thomas wrote:
> We might be able to avoid that be limiting the version to just integers.
> I think that is reasonable but would like to hear some feedback from others.
> 
> That does raise the issue of whether to convert the provided version to
> a (zero padded) string and continue with String compares or to convert
> the version parsed from the session ID to an int. Performance is the
> thing that worries me but I might be over-thinking this. Some
> micro-benchmarks are probably called for.

Ah, it seems this bad feature is spawning ugly hacks :( Why is it a good
idea to append one-more-thing to the session id ? Already with the JVM
route it is costly, and has spawned a ton of bugs (updates not being
made when switching to a new node, etc etc).

Isn't it better to have the mapper simply query the existing managers if
multiple versions exist ?

The algorithm:
- if the Context has old versions active, the mapper will query the
managers to find the right Context
- of match, then you know the context
- otherwise it belongs to the latest version
- if no old versions of a context, no manager lookups, so no cost

I don't agree with adding a version number/id to the session id, or
changing its format, this will create legacy issues, as we can see right
now.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.4

[Remy Maucherat]

On Sun, 2010-10-17 at 22:38 +0100, Mark Thomas wrote:
> Yes, this is stupid but it is what the spec requires.

I have to disagree, there was agreement in the expert group that
wildcard mappings and welcome files cannot be mixed at the moment,
unless for specific proprietary hacks, or if a static file is present.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Creating tomcat VFS

[Remy Maucherat]

On Fri, 2010-10-15 at 08:43 -0700, Costin Manolache wrote:
> But I hope you agree you were right, at least in the long term :-)

Who cares about the long term, nobody uses 10 years old code. Oh,
wait ;)

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Creating tomcat VFS

[Remy Maucherat]

On Fri, 2010-10-15 at 07:57 -0700, Costin Manolache wrote:
> I remember many years back I was arguing in favor of DirContext - pro
> arguments were
> "it's a standard", bundled in JDK, probably more target implementations will
> be available, etc.
> I think Remy was arguing that it's too complex and not a perfect fit. I
> guess he was right :-)

I ended up doing it after complaining for a while. I think it was a
reasonable option at the time, and it was possible to make it fast
enough.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: DO NOT REPLY [Bug 50078] Concurrent access to WeakHashMap in ConcurrentCache causes infinite loop, 100% CPU usage

[Remy Maucherat]

On Thu, 2010-10-14 at 21:44 +1300, Tim Whittington wrote:
> I can have a look at this.
> Is there a preferred way of making this configurable?
> Given the caches are static, it's either going to be system property,
> or changing to using an instance cache retained somewhere appropriate
> (at the moment the builders appear to be instantiated in a lot of
> places).
> 
> Just out of interest, does anyone have any data/experience on the
> behaviour of the eden/pull to eden/weak overflow style of caching vs a
> conventional LRU cache? (not one I've seen used a lot before).

No idea what cache scheme would have top efficiency.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked"

[Remy Maucherat]

On Tue, 2010-09-21 at 10:15 +0200, Wesley Acheson wrote:
> So to get this straight Rémy you think it should be a WONT FIX too?

For the actual resolution, you have to talk with Mark.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked"

[Remy Maucherat]

On Mon, 2010-09-20 at 16:31 -0700, Mark Thomas wrote:
> I agree the spec isn't crystal clear.
> 
> I took the use of the word "partial" to refer to requests and URIs in
> the welcome file to mean that the "complete" request was the result of
> adding the welcome file. With that in mind, it seems natural that the
> filter should apply post welcome file addition. But that is just an
> opinion. I'm still leaning towards WONTFIX.
> 
> I could be convinced that this is a bug but I haven't see anything that
> might support such an argument so far.

If he wants universal filtering, he can use "/*" I think, right ?

As welcome files are not to be done by the default Servlet as a forward,
and a HTTP redirect is not desirable either, there's no possibility to
invoke a Servlet on / with REQUEST.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked"

[Remy Maucherat]

On Tue, 2010-09-14 at 12:26 +0100, Mark Thomas wrote:
> You need to be able to quote the section of the spec that demonstrates
> it is wrong. Having quickly scanned the 2.5 and 3.0 specs I think you
> are going to find that there is no clear definition of whether filters
> are processed before or after welcome files. Currently, Tomcat handles
> welcome files first.
> 
> If you can find some spec language that requires filters to be processed
> before welcome files, the bug is valid. If you can't it is "won't fix"
> and I'll add clarifying the order to my list of issues to raise with the
> EG for Servlet 3.1

Welcome files was never specified as a forward in the first place, since
that's what the user expects to some extent. Similarly, welcome files
without a physical file has also been an area with disagreements.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r988537 - in /tomcat/native/trunk/native: build/tcnative.m4 src/jnilib.c

[Remy Maucherat]

On Tue, 2010-08-24 at 16:56 +0200, jean-frederic clere wrote:
> Well the accept is done in a different thread anyway. Additionally with
> defer accept we won't see any changes accept latency.

Indeed, no change. But Windows is different enough that it would need
significantly different code to be completely optimal. But I don't care
at all about Windows as long as things remains good enough (as I think
it is right now), since without defer accept it will always be inferior
anyway.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r988537 - in /tomcat/native/trunk/native: build/tcnative.m4 src/jnilib.c

[Remy Maucherat]

On Tue, 2010-08-24 at 16:30 +0200, Mladen Turk wrote:
> Work in progress ...
> Will be used in new Poll.interrupt API so we can remove all
> that clumsy pollTime/maintainTime logic for adding new sockets
> to the pollset.
> It should lower the accept latency, remove the need for
> socket add queue and remove unnecessary thread context switches.

What is the usefulness of constantly interrupting polling ? Surely this
will have a cost too. Right now, while polling is in progress, sockets
are queued, and will be added all at once, which presumably will limit
the amount of thread interactions that would require syncing (and only
adding to the queue is synced, which could actually be optimized away by
using some sort of concurrent structure, but unfortunately this is not
so easy to write). Also, maintain does timeouts, which are not done by
polling, I don't see how this can be dropped.

So I don't understand how this can perform better, but feel free to
experiment ;) Maybe on Windows it would yield something (without any
accept filter/defer/whatever, it will suffer from the ms-scale latency,
which is normally not a real world issue, but if it wasn't there it
would be nicer), at the expense of the decent platforms.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r988409 - /tomcat/native/trunk/native/build/tcnative.m4

[Remy Maucherat]

On Tue, 2010-08-24 at 10:23 +0200, Mladen Turk wrote:
> This is for trunk (tcnative 1.2.x)
> Branch 1.1.x will have apr-1.3.x dependency with those
> functions backported after found stable.
> Pool pre cleanup is easily backportable and is
> already part of RHEL-5 apr-1.2.7, so I added extra
> check for that as part of configure.
> 
> 1.4.x will be used since it has apr_pollset_wakeup API
> but only for 1.2.x branch (since this extends Java API)
> 
> All this was explained and put for comments
> for quite some time (March)
> BTW, even you participated in discussion, and think
> we reached consensus on that :)

I don't remember, but I guess I changed my mind then. Real world usage
difficulties mean it is very hard to require something newer than APR
1.3.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r988409 - /tomcat/native/trunk/native/build/tcnative.m4

[Remy Maucherat]

On Tue, 2010-08-24 at 07:02 +, mt...@apache.org wrote:
> Author: mturk
> Date: Tue Aug 24 07:02:44 2010
> New Revision: 988409
> 
> URL: http://svn.apache.org/viewvc?rev=988409&view=rev
> Log:
> Make 1.4.x mandatory at build time as well

This requirement is not possible, even F13 is still at 1.3.9.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r981061 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

[Remy Maucherat]

On Sat, 2010-07-31 at 15:05 +0100, Mark Thomas wrote:
> This appears to fix the crashes on my Mac. Need to test on Windows as 
> well since that is where I first saw the issue.
> 
> I confess to not understanding why this works, just that it appears to 
> do the job.

Assuming it really does something, I don't understand why either.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r964219 [1/2] - in /tomcat/trunk: java/org/apache/catalina/filters/ test/org/apache/catalina/filters/ webapps/docs/ webapps/docs/config/

[Remy Maucherat]

On Wed, 2010-07-14 at 22:11 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Jul 14 22:11:30 2010
> New Revision: 964219
> 
> URL: http://svn.apache.org/viewvc?rev=964219&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48998
> Add the ExpiresFilter, a port of mod_expires
> Patch provided by Cyrille Le Clerc

Isn't the amount of logging high in this filter ? Esp in
getExpirationDate. I didn't try to run it, simply browsing through the
code.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r966882 - in /tomcat/trunk: build.properties.default build.xml checkstyle.xml webapps/docs/changelog.xml

[Remy Maucherat]

On Fri, 2010-07-23 at 19:33 -0700, Bill Barker wrote:
> I'm -1 (vote, not veto) on having validate be a dependency for compile. 

I'm pretty sure Costin will never ever be able to contribute a single
line of code with that check in place :P

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r965150 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/tomcat/util/net/ webapps/docs/ webapps/docs/config/

[Remy Maucherat]

On Wed, 2010-07-21 at 21:36 +0100, Mark Thomas wrote:
> I take it that this means you think there is room for simplification.
> I'm still trying to get my head around the Async implementation so if
> you have any pointers on how it could be simplified, they would be much
> appreciated.

Ok, so for this particular topic, the argument I gave to the expert
group to avoid having to specify a timeout every time was that the
connector timeout was a decent default. This did convince enough people.
I don't see how putting another specific constant is a good idea here.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r965150 - in /tomcat/trunk: java/org/apache/catalina/connector/ java/org/apache/tomcat/util/net/ webapps/docs/ webapps/docs/config/

[Remy Maucherat]

On Wed, 2010-07-21 at 11:18 +0200, Rainer Jung wrote:
> IMHO for any serious application of async the developer will need to 
> adjust the timeout.

I am responsible for the fact that setting the timeout is separate, as I
did not understand how it was meaningful in most cases to have it be
anything other than the usual timeout set by the connector.

I am impressed with the creativity that has been displayed so far on the
async API implementation in Tomcat 7, so I guess that arbitrary 10s
value goes along fine with that.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Vote: Add Checkstyle roleset and make code cleanups!

[Remy Maucherat]

On Thu, 2010-07-08 at 18:02 +0200, Peter Roßbach wrote:
> Hi,
> 
> after the discussion about code style 
> (http://tomcat.markmail.org/thread/2c7lkzmpcuxqpgjj 
> ), I think that we must vote for this fix:
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49268
> It includes a starting point for a very limited checkstyle ruleset.
> 
> +1: progressively introduce checkstyle with checks for which a  
> consensus exists (first TabSpacePolicy, @Version format)
> 0 : More discussion needed
> -1: no checkstyle integration. Tomcat shoudn't have code style rules

-1, but I'm not actually contributing to trunk, so I guess it's only an
opinion.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Chunked encoding should be used also when not using keepalive

[Remy Maucherat]

On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote:
> On 01/04/2010 11:02, Óscar Frías Barranco wrote:
> > What do you think ?
> 
> Seems reasonable but I'd like to hear from some of the other committers
> before making any changes.
> 
> If the change is made, it needs to be made for all connectors, not just
> the BIO connector.

It is not needed in the spec and is more expensive, as closing the
connection is one of the valid content delimitation methods.

His reverse proxy argument is probably the worst one: "connection:
close" does not land in the response by accident, it is added for good
reason. This is just begging for hacks at this point.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r925232 - in /tomcat/trunk: java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/examples/jsp/async/

[Remy Maucherat]

On Mon, 2010-03-22 at 11:05 -0600, Filip Hanik - Dev Lists wrote:
> 2. Since it calls dispatch() before it calls request.setAttribute, it 
> ends up in a loop

For 1), unless the Servlet does startAsync again in the dispatch, it is
complete, even if the servlet does not call complete.

For 2), this is an asynchronous dispatch (dispatch() does not dispatch,
it merely marks for dispatch after the Servlet returns). If you
implemented it synchronously, then this is wrong.

Note: I think you should stop posting or discussing TCK tests publicly.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r921464 - in /tomcat/trunk/java/org/apache/jasper: JspCompilationContext.java servlet/JspServletWrapper.java

[Remy Maucherat]

On Wed, 2010-03-10 at 17:35 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Mar 10 17:35:43 2010
> New Revision: 921464
> 
> URL: http://svn.apache.org/viewvc?rev=921464&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48795
> If compilation fails, always try to re-compile the next time around
> 
> Modified:
> tomcat/trunk/java/org/apache/jasper/JspCompilationContext.java
> tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java

Great idea in theory. Since compilation is an expensive process, this is
likely a dos problem however.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r917931 - /tomcat/trunk/java/org/apache/catalina/core/AprLifecycleListener.java

[Remy Maucherat]

On Tue, 2010-03-02 at 09:19 +, mt...@apache.org wrote:
> Author: mturk
> Date: Tue Mar  2 09:19:45 2010
> New Revision: 917931
> 
> URL: http://svn.apache.org/viewvc?rev=917931&view=rev
> Log:
> With unsafe reneg, minimum required is 1.2.21 caused by API change

As long as you don't set the new flag to true, I think it will work with
old versions.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: EL issues and 6.0.x release

[Remy Maucherat]

On Fri, 2010-01-08 at 11:36 +, Mark Thomas wrote:
> I have some rough code that implements this scheme. I am in the process
> of integrating it into Jasper for trunk. I can see this taking little
> while to iron out the wrinkles before I'll be ready t propose a
> back-port for 6.0.x. I don't think we should hold up the 6.0.x release
> for this. I think it is more important to get the next 6.0.x release out
> than to wait to fix something that has been broken for quite a while anyway.

I don't think making major changes to 6.x to fix edge cases nobody knows
about is a good idea ...

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r893001 - /tomcat/trunk/java/org/apache/jasper/compiler/Generator.java

[Remy Maucherat]

On Mon, 2009-12-21 at 21:51 +, kkoli...@apache.org wrote:
> Author: kkolinko
> Date: Mon Dec 21 21:51:29 2009
> New Revision: 893001
> 
> URL: http://svn.apache.org/viewvc?rev=893001&view=rev
> Log:
> Fix second part of Comment 8 in 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47413#c8
> Coerce result of composite EL expression (${a}${b}) from String to the 
> expected type.

If that really mandatory ?
(if it is, I don't think it is that great to add it in Generator)

Also, an earlier issue: I see void was added as a return type in
JspUtil, but this does not look correct to me.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Releasing Apache Tomcat Native 1.1.18

[Remy Maucherat]

On Wed, 2009-11-18 at 16:18 +0100, jean-frederic clere wrote:
> [X] Stable - no major issues, no regressions
> [ ] Beta   - at least one significant issue -- tell us what it is
> [ ] Alpha  - multiple significant issues -- tell us what they are

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Cookie issues

[Remy Maucherat]

On Thu, 2009-11-12 at 16:03 -0500, Mark Thomas wrote:
> I've done some more digging and I think I have found what was causing this. 
> I'll
> have a fix for trunk shortly and (after some testing) I'll re-propose.

No, what I meant is that, if you want to go the strict route and use '/'
as a separator as well, the behavior is bad. If you create a session
cookie, it will be v0 and will have a path like: $Path=/somepath in it.
The path value cannot be parsed back (enable debug logging to see it).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Cookie issues

[Remy Maucherat]

On Wed, 2009-11-11 at 16:45 -0500, Mark Thomas wrote:
> I really do loath cookies right now. I've pulled the proposed patches for 
> 5.5.x
> and 6.0.x until I (or someone else) can take a look at this.

I do too. v0 cookies is 15 years old stuff that Netscape hacked out of
thin air without thinking at all, and seemingly nobody wants to upgrade
since then :(

The examples in the v1 spec (even the first one) are nice (everything is
always quoted, it's easy and it avoids problems ...), but the problems
occur if you try to enforce it (because the security folks ask for it)
and have to keep v0 support at the same time.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Cookie issues

[Remy Maucherat]

Hi,

I think cookies are still broken, and this is getting more and more
complex. The apparent issue is that the parser applies v1 parsing rules
when parsing v0 cookies (which are generated using a much more lenient
character exclusion), resulting in cookies that cannot be parsed back.

A simple example is a regular cookie session (!), where the path cannot
even be parsed back ('/' is now in the "specials" list).

Maybe we could parse as v0, and validate the bytes if the cookie turned
out to be v1 ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r832039 - in /tomcat/trunk/java/org/apache/naming: HandlerRef.java ResourceRef.java ServiceRef.java StringManager.java resources/DirContextURLStreamHandler.java

[Remy Maucherat]

On Mon, 2009-11-02 at 18:46 +, ma...@apache.org wrote:
> Author: markt
> Date: Mon Nov  2 18:46:21 2009
> New Revision: 832039
> 
> URL: http://svn.apache.org/viewvc?rev=832039&view=rev
> Log:
> StringBuffer -> StringBuilder for o.a.naming

So I did not test or anything, but is SBuilder faster than SBuffer ? Or
it uses less resources ?

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r831536 - in /tomcat/trunk: java/org/apache/tomcat/util/http/ test/org/apache/tomcat/util/http/ webapps/docs/config/

[Remy Maucherat]

On Sat, 2009-10-31 at 12:59 +, ma...@apache.org wrote:
> Author: markt
> Date: Sat Oct 31 12:59:51 2009
> New Revision: 831536
> 
> URL: http://svn.apache.org/viewvc?rev=831536&view=rev
> Log:
> Add an explicit configuration option for cookie version switching and update 
> test cases and docs to include it.

The version switch flag is not correct.

Following a clarification, the Servlet EG has validated the concept of
cookie version switching, to support comments (if a comment is set on
the cookie, then the cookie automatically becomes v1, if it was v0; so
evidently it is now acceptable to switch versions to handle values that
are invalid in v0).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Releasing Apache Tomcat Native 1.1.17

[Remy Maucherat]

On Tue, 2009-10-20 at 21:55 +0200, jean-frederic clere wrote:
> [X] Stable - no major issues, no regressions
> [ ] Beta   - at least one significant issue -- tell us what it is
> [ ] Alpha  - multiple significant issues -- tell us what they are

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r828212 - /tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java

[Remy Maucherat]

On Wed, 2009-10-21 at 20:57 +, ma...@apache.org wrote:
> Author: markt
> Date: Wed Oct 21 20:57:14 2009
> New Revision: 828212
> 
> URL: http://svn.apache.org/viewvc?rev=828212&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47987
> Limit size of not found resources cache

I think you did not modify the right field.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JSR 315 - status ?

[Remy Maucherat]

On Tue, 2009-09-01 at 13:40 +0200, Matthias Wessendorf wrote:
> Is there no Tomcat developer an active member on the JSR ?

You do understand this is confidential information, right ? Follow the
JCP progress and announcements.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[ANN] Apache Tomcat 6.0.20 released

[Remy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 6.0.20 stable. This release includes many bugfixes over Apache
Tomcat 6.0.18.

Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5,
including support for the new Servlet 2.5 and JSP 2.1 specifications, a
refactored clustering implementation, advanced IO features, and
improvements in memory usage.

Please refer to the change log for the list of changes:
http://tomcat.apache.org/tomcat-6.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-60.cgi

Migration guide from Apache Tomcat 5.5.x:
http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.20

[Remy Maucherat]

On Tue, 2009-06-02 at 13:22 -0400, Martin Dubuc wrote:
> What is going to happen to the 6.0.20 load? Will it be officially released?
> If it will, when and will it be identical to the load found at:
> http://people.apache.org/~remm/tomcat-6/v6.0.20/?

I've been in "lazy" mode ...

It has been mirrored, so only the last step remains (updating the
website).

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.20

[Remy Maucherat]

On Thu, 2009-05-14 at 01:33 +0200, Remy Maucherat wrote:
> The candidates binaries are available here:
> http://people.apache.org/~remm/tomcat-6/v6.0.20/
> 
> According to the release process, the 6.0.20 tag is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [ ] Stable

Ok, so with one exception, all voted stable, so it looks like it is good
enough. Last call.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.20

[Remy Maucherat]

On Sun, 2009-05-24 at 17:02 +0400, Konstantin Kolinko wrote:
> I do not see any issues with the release, except the one
> of the tgz sources archive.
> 
> Regarding the tgz archive of the sources I propose the following:
> The build was created on an Unix machine, so the files in the zip
> archive are good enough to rerun the build on unixes.
> 
> Thus, it is sufficient to repack the archive as tgz. I prepared such
> an archive and placed it in
> http://people.apache.org/~kkolinko/tomcat-6/v6.0.20/src/
> 
> md5 sum is
> 6a747d5bfa6b0b57605e8697ca8a4cae *apache-tomcat-6.0.20-src.tar.gz

Hacks were used in the past, but at the moment I prefer if the released
files correspond to the svn tag.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[VOTE] Release build 6.0.20

[Remy Maucherat]

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.20/

According to the release process, the 6.0.20 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r772142 - /tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java

[Remy Maucherat]

On Wed, 2009-05-06 at 10:49 +, ma...@apache.org wrote:
>  // Acquire global JNDI resources if available
> -Server server = ServerFactory.getServer();
> +Server server =
> +
> ((Engine)context.getParent().getParent()).getService().getServer();

Ouch, not pretty.

Rémy



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat Native: APR Http Endpoint handler behavior under Windows

[Remy Maucherat]

On Wed, 2009-04-29 at 08:50 +1000, mcto...@gmail.com wrote:
> A few followups on this.  It's only now that I have realised that the 
> the tomcat apr handler in JBoss is subtly different from the one in 
> Tomcatie that whole piece of tomcat has been forked into JBossWeb, 
> and they're starting to diverge.  Be that as it may, my comments cover 
> the current design as it exists in both of them at trunk level.

The accept code is the same, and that part of the poller code is
equivalent. JBoss Web is my new connector code (that I was doing in the
comet branch here before moving it).

> Why is poller performance bad in Windows? Is that a consequence of the 

I've been told it uses select, which works only on 64 sockets at a time.
So if you have a large poller, then the poll call performance degrades.
Mladen is really the only one who can answer Windows questions.
(personally, I think it is a lot cause for really high scalability)

> way the APR interfaces to WinSock? I'm guessing that APR uses a 
> Unix-style approach to polling the sockets. Or is it to do with the 
> performance of the poll inside Window itself?
> 
> Be that as it may, at our end we still have to make Windows work as well 
> as possible, so if there are simple tweaks we can do to cause 
> performance to degrade more gracefully under conditions of peaky load, 
> can we not discuss it?
> 
> Also I couldn't see where it specifically sets a high number of pollers 
> high for Windows? (And in which fork?? :-)

Both. It's pretty easy, there are Windows specific flags in the code.
Look there. If the poller size is larger than 1024, it creates multiple
pollers, each holding 1024 sockets (my testing did show this was a
magical value, where it was not too slow, yet large enough).

> And could you elaborate please on that last statement? "I'm not sure 
> this whole thing will still be relevant then".

I think APR is by far the best technology for implementing Servlet 3.0,
but I'm not so sure beyond that. The Vista+ enhancements need a new
major version of APR, so it will take some time (too much IMP).

> There seems to be two distinct aspects to this deferAccept thing. One is 
> what happens with the socket options. (And as I understand it this 
> option is only supported in Linux 2.6 anyway).  The other - which is in 
> the AprEndpoint code, concerns the processing of the new connection. 
> Just on that note, I have a question about this bit of code:
> 
> if (!deferAccept) {
> if (setSocketOptions(socket)) {
> getPoller().add(socket);
> } else {
> // Close socket and pool
> Socket.destroy(socket);
> socket = 0;
> }
> } else {
> // Process the request from this socket
> if (!setSocketOptions(socket)
> || handler.process(socket) == 
> Handler.SocketState.CLOSED) {
> // Close socket and pool
> Socket.destroy(socket);
> socket = 0;
> 
> 
> The default value of deferAccept is true, but on Windows this option is 
> not supported in the TCP/IP stack, so there is code that falsifies the 
> flag if this is the case. In which case, the socket is added straight to 
> the poller. I'm happy with that approach anyway.  But, the act of 
> getting it across to the poller  - which should be a relatively quick 
> operation (?) requires the use of a worker thread from the common pool. 
> This gets back to my original point.  If the new connection could be 
> pushed across to the poller asap, (without handling the request), and 
> without having to rely on the worker threads, then surely this is going 
> to degrade more gracefully than the current situation where a busy 
> server is going to leave things in the backlog for quite some time. 
> Which is a problem with a relatively small backlog.

Yes, but (as I said in my previous email):
- Poller.add does sync. This is bad for the Acceptor thread, but it
might be ok.
- Socket options also does SSL handshake, which is not doable in the
Acceptor thread.

So (as I was also saying) if there is no SSL and deferAccept is false,
it is possible to have a configuration option to have the Acceptor
thread set the options and put the socket in the poller without using a
thread from the pool. That is, if you tested it and you found it worked
better for you.

Also, you are supposed to have a large maxThreads in the pool if you
want to scale. Otherwise, although it might work well 99% of the time
since thread use is normally limited due to the poller for keepalive,
it's very easy to DoS your server. BTW, it's rather cheap (on Linux, at
least ;) ).

> In the Tomcat branch, there is code to have multiple acceptor threads, 

That stuff wasn't really implemented. I don't think it's such a good
idea to be too efficient to accept and poll, if all it's going to do is
blow up the app serv