Re: [jetty-users] WAR overlays in Jetty 9.1?
2013/12/13 Jan Bartel j...@intalio.com: I've also implemented a ServletContainerInitializer that does the same thing as the org.jboss.weld.environment.servlet.Listener to set up the weld framework. Using it, I can definitely get your test context listener injected just fine: Brilliant, thank you! I just tested this and it seems to work fine. The only minor exception being a problem on shutting the app down (accessing the injected bean fails in contextDestroyed), but this may be a general Weld or even CDI issue. I can also confirm that in this constellation, the postConstruct on the context listener is called once and only once. I'll see if I can track down why this happened before. Thanks again for your support, this removed a significant obstacle on our migration path to Jetty. Klaus ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] WAR overlays in Jetty 9.1?
2013/12/13 Jan Bartel j...@intalio.com: So I don't know how there could be 2 instances of the same listener, one from the @WebListener and one from web.xml. Maybe add a new Throwable().printStackTrace() in a constructor for the test.ContextListener class and see who is calling it? I've done that and gisted at https://gist.github.com/KlausBrunner/7942040 - however, judging from the line numbers, the problem is likely that this wasn't actually run on the latest commits of yours but on an older version. As I'm not seeing this effect on the latest version (as mentioned before), it's no longer an issue in any case. Sorry for the confusion Klaus ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] jetty httpclient
hi there, is there any reason the httpclient should be used in a servlet ? would putting it in a custom(Proxy)-handler make it lightweighter what need to be consider there (threading...)? thanx ps. i mean jetty 9.x branch ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] AbstractSessionIdManager blocking threads
Hi there,
while performing some load testing of our web-application, we noticed that
all of our threads got BLOCKED by synchronized in the following code in
AbstractSessionIdManager
public String newSessionId(HttpServletRequest request, long created)
{
synchronized (this)
{
while (id==null||id.length()==0||idInUse(id))
}
}
We're using the JDBCSessionIdManager, and since idInUse performs a sql call
in our case, this won't perform well.
We tried using a hazelcast-based session id manager we found on github, but
that too gets stuck (as in threads are BLOCKED) when the load is high
enough.
The question now is, why is this code in a synchronized block? When using a
jdbc-based session id manager, I believe it would make sense to rely on
database mechanisms to ensure sessionids are not reused etc instead of
using a synchronized block'.
Does anyone have any thoughts on this?
Cheers,
Stefan
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
