Re: ForkJoinPool behaviour changed from 9.0.0-M15 to 9.0.0-M17

2017-03-24 Thread Francesco Bassi 
Thanks a lot.
Your support is great and appropriate, as usual.

I still think there's something wrong with this topic, but more on the Java
8 side.
I'll do some more investigations and, in case, involve them!

--fb

On Fri, Mar 24, 2017 at 8:05 PM, Mark Thomas <ma...@apache.org> wrote:

> On 24 March 2017 17:51:27 GMT+00:00, Francesco Bassi <fvba...@gmail.com>
> wrote:
> >Hello.
> >I have a weird problem that happens only wih tomcat 9.0.0-M17+:
> >
> >- I need to process a parallel java stream inside a custom ForkJoinPool
> >
> >If I run the code with 9.0.0-M15, I see that all the threads are
> >properly
> >created using my factory.
> >
> >If I run the code with 9.0.0-M17+, some of the threads that are used in
> >the
> >Stream processing are not coming from my factory, but instead are
> >instance
> >of
> >org.apache.catalina.startup.SafeForkJoinWorkerThreadFactor
> y$SafeForkJoinWorkerThread.
> >
> >
> >Sample prototype code:
> >
> >ForkJoinPool pool = new ForkJoinPool(2, p -> new
> >MyForkJoinWorkerThread(p), null, false);
> >pool.submit(() -> {
> >Stream stream = createMyStream();
> >return stream.parallel().map(t -> {
> >System.out.println("THREAD: " +
> >Thread.currentThread().getClass());
> >return t;
> >}).collect(Collectors.toArrayList());
> >}).get();
> >
> >
> >It seems that something from the newer tomcats "interferes" with the
> >ForkJoinPool mechanism in some weird way.
> >Can someone help me to understand what's going on?
>
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#JRE_Memory_
> Leak_Prevention_Listener_-_org.apache.catalina.core.
> JreMemoryLeakPreventionListener
>
> Look for forkJoinCommonPoolProtection
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

ForkJoinPool behaviour changed from 9.0.0-M15 to 9.0.0-M17

2017-03-24 Thread Francesco Bassi 
Hello.
I have a weird problem that happens only wih tomcat 9.0.0-M17+:

- I need to process a parallel java stream inside a custom ForkJoinPool

If I run the code with 9.0.0-M15, I see that all the threads are properly
created using my factory.

If I run the code with 9.0.0-M17+, some of the threads that are used in the
Stream processing are not coming from my factory, but instead are instance
of
org.apache.catalina.startup.SafeForkJoinWorkerThreadFactory$SafeForkJoinWorkerThread.


Sample prototype code:

ForkJoinPool pool = new ForkJoinPool(2, p -> new
MyForkJoinWorkerThread(p), null, false);
pool.submit(() -> {
Stream stream = createMyStream();
return stream.parallel().map(t -> {
System.out.println("THREAD: " +
Thread.currentThread().getClass());
return t;
}).collect(Collectors.toArrayList());
}).get();


It seems that something from the newer tomcats "interferes" with the
ForkJoinPool mechanism in some weird way.
Can someone help me to understand what's going on?

thanks,

--fb

Tomcat 9.0.0M4 (and trunk) issue with Websockets (bug?)

2016-04-04 Thread Francesco Bassi 
Hello everybody.

Tomcat 9 has a different behaviour than Tomcat 8, during the management of
MessageHandler.onMessage:

- in Tomcat 8:
  Thread.currentThread().getContextClassLoader() returns an instance of
org.apache.catalina.loader.WebappClassLoader

- in Tomcat 9
  Thread.currentThread().getContextClassLoader() returns an instance of
java.net.URLClassLoader
  (which doesn't resolve the WEB-INF/lib/* classes)

It seems to be related to the switch to ParallelWebappClassLoader.
Is it a bug or and intended behaviour?

Thanks,

--fb

Tomcat 8.0.5, .jsp Java 8 interface static methods

2014-04-07 Thread Francesco Bassi 
Hello everybody.

Since 8.0.5, it seems that .jsps that include invocations of static
interface methods don't work anymore.

Here's an example:

Test.java;

package com.wfb.test;
public interface Test {
public static String getText() { return Gotcha!; }
}

test.jsp
%String s = com.wfb.test.Test.getText();%

Tomcat says:

org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: 1 in the jsp file: /test.jsp
This static method of interface Test can only be accessed as Test.getText
1: %String s = com.wfb.test.Test.getText();%


Stacktrace:

org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)

org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)

org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:475)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:380)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

com.wfb.web.container.EnvironmentFilter.doFilter(EnvironmentFilter.java:33)

com.wfb.web.container.log4j.Log4JEnvironmentFilter.doFilter(Log4JEnvironmentFilter.java:57)

org.apache.logging.log4j.core.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:66)

Re: Tomcat 8.0.5, .jsp Java 8 interface static methods

2014-04-07 Thread Francesco Bassi 
Well...

I'm using 8.0.3 (and before I used to use 8.0 RC something) and the access
to the static interface methods are working pretty well...


On Mon, Apr 7, 2014 at 4:17 PM, Mark Thomas ma...@apache.org wrote:

 On 07/04/2014 12:25, Francesco Bassi wrote:
  Hello everybody.
 
  Since 8.0.5, it seems that .jsps that include invocations of static
  interface methods don't work anymore.

 What do you mean any more? The changes necessary to support that out of
 the box (updated JDT compiler) weren't available until 8.0.5.

 Also, have you changed the defaults for compilerSourceVM and
 compilerTargetVMas they will be 1.7 by default (i.e. Java 7, not Java 8).

 Mark



 
  Here's an example:
 
  Test.java;
 
  package com.wfb.test;
  public interface Test {
  public static String getText() { return Gotcha!; }
  }
 
  test.jsp
  %String s = com.wfb.test.Test.getText();%
 
  Tomcat says:
 
  org.apache.jasper.JasperException: Unable to compile class for JSP:
 
  An error occurred at line: 1 in the jsp file: /test.jsp
  This static method of interface Test can only be accessed as Test.getText
  1: %String s = com.wfb.test.Test.getText();%
 
 
  Stacktrace:
 
 org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
 
 org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)
 
 org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:475)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:380)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
 
 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
 
 com.wfb.web.container.EnvironmentFilter.doFilter(EnvironmentFilter.java:33)
 
 com.wfb.web.container.log4j.Log4JEnvironmentFilter.doFilter(Log4JEnvironmentFilter.java:57)
 
 org.apache.logging.log4j.core.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:66)
 


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

Re: Tomcat 8.0.5, .jsp Java 8 interface static methods

2014-04-07 Thread Francesco Bassi 
Sorry!!!
Please disregard the whole topic.

I forgot to set these parameters.

Now everything is working great.

Thanks again for your usual great support!




On Mon, Apr 7, 2014 at 4:33 PM, Francesco Bassi fvba...@gmail.com wrote:

 Well...

 I'm using 8.0.3 (and before I used to use 8.0 RC something) and the access
 to the static interface methods are working pretty well...


 On Mon, Apr 7, 2014 at 4:17 PM, Mark Thomas ma...@apache.org wrote:

 On 07/04/2014 12:25, Francesco Bassi wrote:
  Hello everybody.
 
  Since 8.0.5, it seems that .jsps that include invocations of static
  interface methods don't work anymore.

 What do you mean any more? The changes necessary to support that out of
 the box (updated JDT compiler) weren't available until 8.0.5.

 Also, have you changed the defaults for compilerSourceVM and
 compilerTargetVMas they will be 1.7 by default (i.e. Java 7, not Java 8).

 Mark



 
  Here's an example:
 
  Test.java;
 
  package com.wfb.test;
  public interface Test {
  public static String getText() { return Gotcha!; }
  }
 
  test.jsp
  %String s = com.wfb.test.Test.getText();%
 
  Tomcat says:
 
  org.apache.jasper.JasperException: Unable to compile class for JSP:
 
  An error occurred at line: 1 in the jsp file: /test.jsp
  This static method of interface Test can only be accessed as
 Test.getText
  1: %String s = com.wfb.test.Test.getText();%
 
 
  Stacktrace:
 
 org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
 
 org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)
 
 org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:475)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:380)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
 
 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
 
 com.wfb.web.container.EnvironmentFilter.doFilter(EnvironmentFilter.java:33)
 
 com.wfb.web.container.log4j.Log4JEnvironmentFilter.doFilter(Log4JEnvironmentFilter.java:57)
 
 org.apache.logging.log4j.core.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:66)
 


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

Tomcat 7.0.48-dev WebSockets: NullPointerException on WsServerContainer.unregisterAuthenticatedSession

2013-11-28 Thread Francesco Bassi 
Hello everybody.

I have a doubt:

whenever the HttpSession expires, I get a NullPointerException on
WsServerContainer.unregisterAuthenticatedSession

in this line:

private void unregisterAuthenticatedSession(WsSession wsSession,
String httpSessionId) {
SetWsSession wsSessions =
authenticatedSessions.get(httpSessionId);
--wsSessions.remove(wsSession);
}


The quick fix is obvious:

private void unregisterAuthenticatedSession(WsSession wsSession,
String httpSessionId) {
SetWsSession wsSessions =
authenticatedSessions.get(httpSessionId);
if(wsSessions!=null) wsSessions.remove(wsSession);
}

but I suspect that the error is elsewhere.

What do you think?

Re: Tomcat 7.0.48-dev WebSockets: NullPointerException on WsServerContainer.unregisterAuthenticatedSession

2013-11-28 Thread Francesco Bassi 
Thanks a lot for your prompt support.
Definitely a serious reason not to switch to any other application server!


On Thu, Nov 28, 2013 at 3:29 PM, Mark Thomas ma...@apache.org wrote:

 On 28/11/2013 14:06, Francesco Bassi wrote:
  Hello everybody.
 
  I have a doubt:
 
  whenever the HttpSession expires, I get a NullPointerException on
  WsServerContainer.unregisterAuthenticatedSession
 
  in this line:
 
  private void unregisterAuthenticatedSession(WsSession wsSession,
  String httpSessionId) {
  SetWsSession wsSessions =
  authenticatedSessions.get(httpSessionId);
  --wsSessions.remove(wsSession);
  }
 
 
  The quick fix is obvious:
 
  private void unregisterAuthenticatedSession(WsSession wsSession,
  String httpSessionId) {
  SetWsSession wsSessions =
  authenticatedSessions.get(httpSessionId);
  if(wsSessions!=null) wsSessions.remove(wsSession);
  }
 
  but I suspect that the error is elsewhere.
 
  What do you think?

 The quick fix looks like the right fix to me.

 I've applied the fix to trunk for 8.0.0-RC6 and 7.0.x for 7.0.48.

 Mark


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

Re: Tomcat 7.0.47 Websocket + JNDI problems

2013-10-28 Thread Francesco Bassi 
I confirm that using the 7.0 trunk from SVN
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk
everything is working fine, now.
(ie: the current thread classloader is WebappClassLoader and the JNDI
context is properly loaded)

Thanks a lot for the quick response.


On Mon, Oct 28, 2013 at 11:07 AM, Mark Thomas ma...@apache.org wrote:

 On 28/10/2013 08:49, Mark Thomas wrote:
  On 27/10/2013 22:41, Konstantin Kolinko wrote:
  2013/10/28 Francesco Bassi fvba...@gmail.com:
  Hello everybody.
 
  I just downloaded 7.0.47 and updated one web application that I
 developed
  in order to use the new standard JSR 356 websocket implementation.
 
  With this new implementation, I noticed that during the processing of
  incoming websocket events, it's not possible to access the JNDI
 resources.
 
  ie:
 
  Context initCtx = new InitialContext();
  Context c = (Context) initCtx.lookup(java:comp/env);
 
  gives
 
  javax.naming.NameNotFoundException: Name [comp/env] is not bound in
 this
  Context. Unable to find [comp].
 
  I'm using a custom ServerEndpointConfig.Configurator.
 
  Everything used to work properly with the old custom tomcat
 implementation.
 
  Is it an expected behaviour?
 
 
  I think it means that  the thread where you process those events does
  not have its Thread.getContextClassLoader() (aka TCCL) configured and
  thus JNDI does not know to what web application this thread belongs.
 
  Can you provide the stack trace of the place where you access JNDI
  and check what is the value of
  Thread.currentThread().getContextClassLoader() there?
 
  If the class loader is not a o.a.c.loader.WebappClassLoader one, I
  think it is OK to create a bugzilla issue.
 
  Agreed. I'll see if I can find the bug by code inspection but a stack
  trace would be quicker.

 I think I've found all the places this can happen and I've fixed them
 for 8.0.x and 7.0.x. If you could test with either of those (you'll need
 to build the latest 7.0.x or 8.0.x from svn) to confirm that the fix
 works for you that would be very helpful.

 Mark


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

Fwd: Tomcat 7.0.47 Websocket + JNDI problems

2013-10-27 Thread Francesco Bassi 
Hello everybody.

I just downloaded 7.0.47 and updated one web application that I developed
in order to use the new standard JSR 356 websocket implementation.

With this new implementation, I noticed that during the processing of
incoming websocket events, it's not possible to access the JNDI resources.

ie:

Context initCtx = new InitialContext();
Context c = (Context) initCtx.lookup(java:comp/env);

gives

javax.naming.NameNotFoundException: Name [comp/env] is not bound in this
Context. Unable to find [comp].

I'm using a custom ServerEndpointConfig.Configurator.

Everything used to work properly with the old custom tomcat implementation.

Is it an expected behaviour?

thanks,

--fb