Re: [jetty-users] Unable to render Velocity Template
Sounds like the linux tmp folder is cleaned up every now and then. You can make jetty use a different tmp folder in order to prevent issue. See docs. Stefan 2015-01-28 12:26 GMT+01:00 Eduardo Fiss Beloni ebel...@voiza.com.br: Hello, We are having loads of Unable to render Velocity Template throughout the jetty logs. Then the user can't see the site anymore. 2015-01-26 10:20:38,751 [qtp399631128-23 ERROR CommonsLogger]: Unable to render Velocity Template, '/error.vm' org.apache.velocity.exception.VelocityException: Exception rendering #parse(/_inc/footer.vm) at /error.vm[line 67, column 9] ... ... 2015-01-25 23:07:34,732 [qtp1819130381-4849 ERROR CommonsLogger]: Unable to render Velocity Template, '/super/aba_vitrine.vm' org.apache.velocity.exception.VelocityException: VelocimacroProxy.render() : exception VM = #produto() It happens a few times a month. When this happens the only way to bring our frontend servers back is to restart jettys. This started to happen when we updated from jetty 7 to jetty 9.1.3. Could this be a jetty parameter or something? Thank you, Eduardo Fiss Beloni ebel...@voiza.com.br www.voiza.com.br Soluções em Java (51) 4063-8913 - Porto Alegre (53) 4062-9183/3222-1833 - Pelotas ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] gzip filter
Have you verified all this? GZIP Filter This filter will gzip or deflate the content of a response if: - The filter is mapped to a matching path - accept-encoding header is set to either gzip, deflate or a combination of those - The response status code is =200 and 300 - The content length is unknown or more than the minGzipSize initParameter or the minGzipSize is 0(default) - If a list of mimeTypes is set by the mimeTypes init parameter, then the Content-Type is in the list. - If no mimeType list is set, then the content-type is not in the list defined by excludedMimeTypes - No content-encoding is specified by the resource 2015-01-12 12:32 GMT+01:00 Andrew Penhorwood penhorw...@gmail.com: I am using chrome and I can see the gzip accept headers in the request. I can also see that the file size never changes when it comes across the wire. On Mon, Jan 12, 2015 at 2:15 AM, Christoph Läubrich lae...@googlemail.com wrote: Gzip must be requested by the client, have you checked that the client actually request compressed data? What client do you use? Also make sure your files have proper mime types and try to enable only for a specific mime type to test. Beside this: How do you verify that content is Gzipped? Some versions of IE+Firebug Console do not report the gzip content type. So you should actually check with wire-shark or a simple java test client (just make sure to request compression!) Am 11.01.2015 20:14, schrieb Andrew Penhorwood: I am using jetty9.2.6. The site has ran for months without issue on the Jetty 9.2.x codes bases. I decided to audit the site to see if there were things we could do to make it more efficient. One of those things was enabling gzip. So I added the gzip filter to to my webdefault.xml file. ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users -- Andrew Penhorwood and...@coldbits.com www.coldbits.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] gzip filter
I recommend using curl or wget and request gzipped content (add accept-encoding: gzip header). Then you'll actually get gzip stored on your disk, and you'll have to gunzip the content manually. Stefan 2015-01-12 8:15 GMT+01:00 Christoph Läubrich lae...@googlemail.com: Gzip must be requested by the client, have you checked that the client actually request compressed data? What client do you use? Also make sure your files have proper mime types and try to enable only for a specific mime type to test. Beside this: How do you verify that content is Gzipped? Some versions of IE+Firebug Console do not report the gzip content type. So you should actually check with wire-shark or a simple java test client (just make sure to request compression!) Am 11.01.2015 20:14, schrieb Andrew Penhorwood: I am using jetty9.2.6. The site has ran for months without issue on the Jetty 9.2.x codes bases. I decided to audit the site to see if there were things we could do to make it more efficient. One of those things was enabling gzip. So I added the gzip filter to to my webdefault.xml file. ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Single page application routing
Ok. Use a servlet instead then in the mapping and have it redirect to the
correct page
Sendt fra min iPhone
Den 22. des. 2014 kl. 10.22 skrev Dmitry Polovka messa...@messaged.lv:
Adding a 404 error-page to web.xml does the trick, but it sends actual 404
status code in header. I need 200.
On 22 Dec 2014, at 05:57, Stefan Magnus Landrø stefan.lan...@gmail.com
wrote:
Adding a 404 error-page to web.xml should do the trick.
Stefan
Den 21. des. 2014 kl. 21.50 skrev Dmitry Polovka messa...@messaged.lv:
Hey everybody, i am beginner. Can somebody advise me on how to manage
single page application routing?
I need DefaultServlet to work as it works now - serve static content,
handle ETags and do other stuff.
Since JS will handle routing, on unknown route to Jetty, Jetty will throw
404 and i need to intercept these 404 errors
to output content of index.html and let JS do the work.
What is the best way to do that?
Launcher.java
-
public static void main(String[] args) throws Exception
{
Server server = new Server();
// Remove Server:Jetty(9...) from Response Headers
HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSendServerVersion(false);
HttpConnectionFactory httpFactory = new HttpConnectionFactory(httpConfig);
ServerConnector connector = new ServerConnector(server, httpFactory);
connector.setPort(8080);
server.addConnector(connector);
WebAppContext context = new WebAppContext(webapp, /);
context.addServlet(new ServletHolder(new DefaultServlet()), /*);
// Map WebSocket to listen on `/ws`
Broker broker = new Broker();
context.addServlet(new ServletHolder( new Servlet(broker)), /ws);
// Setting up browser caching. Binds params for
org.eclipse.jetty.servlet.DefaultServlet.init()
context.setInitParameter(org.eclipse.jetty.servlet.Default.etags,
true);
context.setInitParameter(org.eclipse.jetty.servlet.Default.cacheControl,
public, max-age=0);
// Disallow directory listing
context.setInitParameter(org.eclipse.jetty.servlet.Default.dirAllowed,
false);
// Search for index.html/index.jsp pages
context.setInitParameter(org.eclipse.jetty.servlet.Default.welcomeServlets,
true);
// Fix for Windows, so Jetty doesn't lock files
if (System.getProperty(os.name).toLowerCase().contains(windows)) {
context.setInitParameter(org.eclipse.jetty.servlet.Default.useFileMappedBuffer,
false);
}
// Will throw an exception when will be unable to start server for some
reason
context.setThrowUnavailableOnStartupException(true);
server.setHandler(context);
server.start();
}
—
I also have jersey mapping in web.xml
servlet-mapping
servlet-namejersey-api-v1/servlet-name
url-pattern/api/v1/*/url-pattern
/servlet-mapping
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Single page application routing
Adding a 404 error-page to web.xml should do the trick.
Stefan
Den 21. des. 2014 kl. 21.50 skrev Dmitry Polovka messa...@messaged.lv:
Hey everybody, i am beginner. Can somebody advise me on how to manage single
page application routing?
I need DefaultServlet to work as it works now - serve static content, handle
ETags and do other stuff.
Since JS will handle routing, on unknown route to Jetty, Jetty will throw 404
and i need to intercept these 404 errors
to output content of index.html and let JS do the work.
What is the best way to do that?
Launcher.java
-
public static void main(String[] args) throws Exception
{
Server server = new Server();
// Remove Server:Jetty(9...) from Response Headers
HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSendServerVersion(false);
HttpConnectionFactory httpFactory = new HttpConnectionFactory(httpConfig);
ServerConnector connector = new ServerConnector(server, httpFactory);
connector.setPort(8080);
server.addConnector(connector);
WebAppContext context = new WebAppContext(webapp, /);
context.addServlet(new ServletHolder(new DefaultServlet()), /*);
// Map WebSocket to listen on `/ws`
Broker broker = new Broker();
context.addServlet(new ServletHolder( new Servlet(broker)), /ws);
// Setting up browser caching. Binds params for
org.eclipse.jetty.servlet.DefaultServlet.init()
context.setInitParameter(org.eclipse.jetty.servlet.Default.etags,
true);
context.setInitParameter(org.eclipse.jetty.servlet.Default.cacheControl,
public, max-age=0);
// Disallow directory listing
context.setInitParameter(org.eclipse.jetty.servlet.Default.dirAllowed,
false);
// Search for index.html/index.jsp pages
context.setInitParameter(org.eclipse.jetty.servlet.Default.welcomeServlets,
true);
// Fix for Windows, so Jetty doesn't lock files
if (System.getProperty(os.name).toLowerCase().contains(windows)) {
context.setInitParameter(org.eclipse.jetty.servlet.Default.useFileMappedBuffer,
false);
}
// Will throw an exception when will be unable to start server for some
reason
context.setThrowUnavailableOnStartupException(true);
server.setHandler(context);
server.start();
}
—
I also have jersey mapping in web.xml
servlet-mapping
servlet-namejersey-api-v1/servlet-name
url-pattern/api/v1/*/url-pattern
/servlet-mapping
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Configuring Jetty to modify the head element
Place a servlet filter at the start/end of the chain. You'll have to modify the web.xml and add class with filter impl to class path. Sendt fra min iPhone Den 11. des. 2014 kl. 15.45 skrev Michael Monaghan mick...@gmail.com: Hi, For testing purposes, I need to modify the head element of all the text/html content generated by a large complicated app. I need to add a JavaScript include to the head element. The work required to do this in the app itself is likely not trivial. I don't own the app, and don't fully understand the architecture etc. There's little or no static HTML here. Is it possible to have Jetty modify the head element of the content that it serves? Thanks for your time. ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Configuring Jetty to modify the head element
Maybe use a response wrapper and buffer response to prevent the response commited issue? Sendt fra min iPhone Den 11. des. 2014 kl. 16.19 skrev Joakim Erdfelt joa...@intalio.com: That can be very tricky. First, there's no built-in function to do that. So you'll have to write the html parsing modification routines yourself. This could be done via a Servlet Filter or a Jetty HandlerWrapper, in either approach you'll want to wrap the HttpServletResponse to capture modify the response, and pass that wrapper down into the filter chain (or handler wrapper chain). Tip: response isCommitted can be a point of no return (esp for response Content-Length), so keep that mind. -- Joakim Erdfelt joa...@intalio.com webtide.com - intalio.com/jetty Expert advice, services and support from from the Jetty CometD experts eclipse.org/jetty - cometd.org On Thu, Dec 11, 2014 at 7:45 AM, Michael Monaghan mick...@gmail.com wrote: Hi, For testing purposes, I need to modify the head element of all the text/html content generated by a large complicated app. I need to add a JavaScript include to the head element. The work required to do this in the app itself is likely not trivial. I don't own the app, and don't fully understand the architecture etc. There's little or no static HTML here. Is it possible to have Jetty modify the head element of the content that it serves? Thanks for your time. ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] BadMessage 400 Unknown Version
Unknown http version?
Sendt fra min iPhone
Den 28. nov. 2014 kl. 17.30 skrev Eduardo Beloni ebel...@voiza.com.br:
Hello everyone,
We have jetty 9.1.3 running over here and we are getting the following
warning over and over again every 2 or 3 seconds:
...
2014-11-28 09:33:43.503:WARN:oejh.HttpParser:qtp1501313317-16: badMessage:
400 Unknown Version for HttpChannelOverHttp@74fe9f46{r=0,a=IDLE,uri=-}
2014-11-28 09:33:45.675:WARN:oejh.HttpParser:qtp1501313317-13: badMessage:
400 Unknown Version for HttpChannelOverHttp@3a1aedef{r=0,a=IDLE,uri=-}
2014-11-28 09:33:48.505:WARN:oejh.HttpParser:qtp1501313317-20: badMessage:
400 Unknown Version for HttpChannelOverHttp@3a70d701{r=0,a=IDLE,uri=-}
2014-11-28 09:33:50.690:WARN:oejh.HttpParser:qtp1501313317-20: badMessage:
400 Unknown Version for HttpChannelOverHttp@28d3dd3f{r=0,a=IDLE,uri=-}
2014-11-28 09:33:53.508:WARN:oejh.HttpParser:qtp1501313317-15: badMessage:
400 Unknown Version for HttpChannelOverHttp@5b1f5a5e{r=0,a=IDLE,uri=-}
...
...
Do you have any idea of what might be causing this warning and possibly how
to prevent it from happening?
Thank you,
Eduardo Fiss Beloni
ebel...@voiza.com.br
www.voiza.com.br
Soluções em Java
(51) 4063-8913 - Porto Alegre
(53) 4062-9183/3222-1833 - Pelotas
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] badMessage: 400 No URI for HttpChannelOverHttp@61addd0d{r=1, c=false, a=IDLE, uri=-}
Hi there,
After placing an apache server (w/ mod security and mod proxy) and a f5 big
ip (load balancer) between f5 big ip (load balancer) and jetty, we started
seeing bad requests in our logs:
badMessage: 400 No URI for HttpChannelOverHttp@61addd0d
{r=1,c=false,a=IDLE,uri=-}
I looked at the code, but don't really understand what an IDLE request is.
Anyone?
Cheers,
Stefan
BTW, we're using jetty-9.2.3.v20140905
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] NoClassDefFoundError
Could it be that the classes are stored in your tmp folder and occasionally get wiped by your os (or your admin)? Are the actual class files actually found on disk? Stefan 2014-11-04 11:56 GMT+01:00 Per Jørgen Vigdal per.jorgen.vig...@evry.com: Hi Here is an example of the stack trace : java.lang.NoClassDefFoundError: no/ergo/reseptformidleren/webservices/rekvirent/m271/x20130416/vo/M27_1Vo at no.ergo.reseptformidleren.webservices.rekvirent.m271.x20130416.M271Impl.init(M271Impl.java:56) ~[classes/:na] at no.ergo.reseptformidleren.webservices.rekvirent.RekvirentWebService.getM271Common(RekvirentWebService.java:1049) ~[classes/:na] at no.ergo.reseptformidleren.webservices.rekvirent.RekvirentWebService.m27_1(RekvirentWebService.java:1011) ~[classes/:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_18] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_18] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_18] at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_18] at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:250) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:149) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:88) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1063) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:979) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:950) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:825) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:380) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:651) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:264) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:218) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:159) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:194) [webservices-rt.jar:2.2.1] at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:80) [webservices-rt.jar:2.2.1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) [servlet-api-3.0.jar:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) [servlet-api-3.0.jar:na] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) [jetty-servlet-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) [jetty-servlet-8.1.12.v20130726.jar:8.1.12.v20130726] at no.ergo.reseptformidleren.webservices.felles.util.SOAPServletFilter.doFilter(SOAPServletFilter.java:145) [classes/:na] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) [jetty-servlet-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) [jetty-servlet-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) [jetty-server-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) [jetty-security-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) [jetty-server-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) [jetty-server-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) [jetty-servlet-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) [jetty-server-8.1.12.v20130726.jar:8.1.12.v20130726] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
Re: [jetty-users] Does openSSL CVE-2014-0160 effect jetty users?
Well, if you use Tomcat with JBoss, you can actually plug in OpenSSL quite easily... 2014-04-09 11:51 GMT+02:00 Lothar Kimmeringer j...@kimmeringer.de: Am 09.04.2014 11:13, schrieb Peter Ondruška: On Wednesday, 9 April 2014, maarten ligtvoet maartenligtv...@gmail.commailto: maartenligtv...@gmail.com wrote: Does the openSSL heartbleed bug effect jetty users? Jetty uses Java VM's SSL, not OpenSSL. and to continue the answer: Since the SSL-implementation should be in Pure Java, missing boundary-checks aren't a topic there. A final answer depends on the configuration of your JVM, though. In theory, you can change the SSLSocketFactory by one that actually uses OpenSSL via JNI, but that's something never being heard of - at least by me. Regards, Lothar ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Help with file not found
To me this looks like a relative/absolute path issue in the file which tries to include the last parser.js. Stefan 2014-03-04 16:11 GMT+01:00 Eliza Nguyen eliza_n...@yahoo.com: Hi, I am using Jetty 9 as local web server (no servlet). In my html, I import several css files js files. Those files are found. However, after there are errors about files in the same directory not found. It looks like the directory is moved up 1 level. Actual directory in Windows Explorer \jetty-distribution-9.1.2.v20140210\webapps\WebContent\dojo-release-1.9.1\dojo File found: [07:05:51.348] GET http://localhost:8080/WebContent/index_eliza.html[HTTP/1.1 200 OK 16ms] [07:05:51.515] GET http://localhost:8080/WebContent/dojo-release-1.9.1/dojo/dojo.js[HTTP/1.1 200 OK 0ms] [07:05:51.516] GET http://localhost:8080/WebContent/js/boot.js [HTTP/1.1 200 OK 0ms] [07:05:51.517] GET http://localhost:8080/WebContent/dojo-release-1.9.1/dijit/themes/claro/claro.css[HTTP/1.1 200 OK 16ms] ... File not found: -- WebContent directory (my root directory) is no longer in the path [07:05:52.648] GET http://localhost:8080/dojo-release-1.9.1/dojo/parser.js[HTTP/1.1 404 Not Found 0ms] Thank you very much for your help, Eliza ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] JDBCSessionManager dirty operations
Hi there,
the problem here isn't really the synchronized block itself. The problem is
that the different synchronization blocks cover lots of remote sql calls (@
let's say 10ms each). Do the math - you'll notice how few session related
operations you can do per second per jvm ...
In my opinion, the jdbc-/(abstract-)session(id)manager code needs a
complete rewrite.
Stefan
2014-02-27 8:48 GMT+01:00 lord.bud...@gmail.com:
Indeed, tomcat uses a concurrent hash map and no explicit synchronisation
when accessing/updating session attributes.
And in fact tomcat only uses synchronized in two places, when expiring the
session and when fire events to session listeners.
Yeah, I hear that synchronisation is not such an overhead, but then put
large load on big multi socket multicore box and watch it completely fail
to scale to the available hardware.
On 27 February 2014 20:35, lord.bud...@gmail.com wrote:
Ouch. Just looked at the
AbstractSessionManagerhttp://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.1.0.v20131115/org/eclipse/jetty/server/session/AbstractSessionManager.java#AbstractSessionManager...
Such synchronisation is the tip of the iceberg.
I wonder if there really needs to be this amount of synchronisation when
the order of the requests coming in that might affect a session can be
quote arbitrary in themselves. On AbstractSessionManager synchronisation
protection on _attributes is perhaps overkill when a ConcurrentHashMap
could be used instead.
On 27 February 2014 20:02, lord.bud...@gmail.com wrote:
I don't believe the synchronised block is useful here. Synchronised
should be used to stop things breaking, not to protect against something
that is occasionally inefficient.
So this is sufficient and will avoid inconsistent synchronization
warnings...
@Override
public void removeAttribute(String name) {
if(getAttribute(name)){
super.removeAttribute(name);
_dirty = true;
}
}
On 27 February 2014 10:40, Jan Bartel j...@intalio.com wrote:
Cemo,
This will need some refactoring of the implementation of the session
interface, but I'm not opposed to looking into it.
Can you open a bug for this please and assign to me?
thanks
Jan
On 27 February 2014 06:25, Cemo cemalettin@gmail.com wrote:
Hi,
Current org.eclipse.jetty.server.session.JDBCSessionManager has
removeAttribute as this:
public void removeAttribute (String name)
{
super.removeAttribute(name);
_dirty=true;
}
This has a side effect because of making dirty for every removing
operation.
This is causing a lot of trouble because each jstl set ( c:set ) call
in JSP
pages is also calling removeAttribute internally. What I am
suggesting is
that something like this:
@Override
public void removeAttribute(String name) {
synchronized (this){
Object attribute = getAttribute(name);
if(attribute != null){
super.removeAttribute(name);
_dirty = true;
}
}
}
public
https://gist.github.com/cemo/9236abe34d2b126242ad
What do you think?
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel j...@intalio.com
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
--
BEKK Open
http://open.bekk.no
TesTcl - a unit test framework for iRules
http://testcl.com
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] BindException: Address already in use
This basically means someone else (the old jetty?) is listening on that port already. Hth Stefan Sendt fra min iPhone Den 12. feb. 2014 kl. 18:44 skrev Eliza Nguyen eliza_n...@yahoo.com: Hi all, While waiting for the new version of Jetty, I am playing with Jetty version 8.1.144. when type java -jar start.jar on the command line, I got error below. java.net.BindException: Address already in use Please help. Thanks ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 9.1.2 release date?
perfect. Thanks! 2014-02-05 Jesse McConnell jesse.mcconn...@gmail.com: we are working on it, lots of niggling little issues we want to address and get in for the release keep pushing it back hopefully stage this week though jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Feb 5, 2014 at 2:55 AM, Stefan Magnus Landrø stefan.lan...@gmail.com wrote: Hi, Any clue when jetty 9.1.2 will be out? Cheers Stefan ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Upgrading to Jetty 9.1
2014-01-28 lord.bud...@gmail.com We also use selective chunking but _do_ use one connect. Any reason why you have one connect off ? Not really. Historic reasons. Will switch it on soon. Oh, the request header X-Forwarded-SSL.I thought Jetty looks for X-Forwarded-Proto with value https to enable secure session cookies. Indeed, this is historic too. We actually don't use it any more. Have to do some cleaning up in the iRules... BTW, if you're into irules, you should give my irule testing framework a go: testcl.com Oh, and totally irrelevant, why are your session cookies so huge and containing a repeat of the first part. Feel free to ignore this :) We're using the jdbc session id manager - it allows us to perform deploys without downtime. The first/last parts identify a hashed version of the hostname. Btw, performance-wise it sucks (there is lots of synchronization code in the AbstractSession(Id)Manager) - that's why we're in the process of writing our own Hazelcast-based session manager from scratch (without all the synchro code). Using jdbc, we can't do more than 10-20 logins per second per server, and that will give us problems down the road. On 29 January 2014 00:30, Stefan Magnus Landrø stefan.lan...@gmail.comwrote: Hi there, I've been looking further into the issue, and it seems clear what is going on. This is what happens when running requests through our big ip (not using one connect): jetty 9.1: whenever a request contains a connection:keep-alive header (the default for all browsers I believe, but not for curl), curl hangs until the keep alive timeout is reached. Also, jetty replies with a connection: keep-alive header in the response. whenever a request does not contain a connection:keep-alive header, curl does not hang, and jetty doesn't add a connection:keep-alive to the response jetty 8: it doesn't matter if the request contains a connection:keep-alive header or not, curl does not hang under any circumstance and jetty will never add a connection:keep-alive header in the response. In addition, it turns out that big ip, removes the transfer-encoding:chunked header that jetty generated (see local debug block) from the response (we're using the recommended selective response chunking mode in the big ip http profile). In my opinion that is wrong, since it doesn't add the Content-Length header, something which would require the connection to be closed in order for the client to know when there is no more content. BTW, the servlet is spitting out the request headers as-is. Comments, anyone? * Jetty 9.1 (through big ip) * ➜ tmp curl -i https://whereever.no HTTP/1.0 200 Connection established HTTP/1.1 200 OK X-MiniProfiler-Ids: [c2600ed9-5e37-4d86-bfd0-f6330c818961] Set-Cookie: SESSION_COOKIE=f71e3e84ab741db2c5a8d20df07ee098g74r8cd0loxh65ry63fq5mle.f71e3e84ab741db2c5a8d20df07ee098;Path=/;Secure;HttpOnly Expires: Thu, 01 Jan 1970 00:00:00 GMT X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Permitted-Cross-Domain-Policies: master-only X-Content-Type-Options: nosniff Content-Security-Policy-Report-Only: default-src 'none'; report-uri /post/cspreport/ Cache-Control: no-cache, no-store, no-transform Content-Type: text/plain Set-Cookie: BIGipServerpool_sticky=111834251.3879.; path=/ Vary: Accept-Encoding Header name X-Forwarded-SSL - Header true Header name X-Forwarded-For - Header 139.112.144.209 Header name User-Agent - Header curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5 Header name Accept - Header */* Header name Host - Header whereever.no Does not hang +++ curl -i -H *Connection: Keep-Alive* https://whereever.no HTTP/1.0 200 Connection established HTTP/1.1 200 OK X-MiniProfiler-Ids: [7549c3f2-c396-4b26-802d-40350aa64d4c] Set-Cookie: SESSION_COOKIE=f71e3e84ab741db2c5a8d20df07ee0981q2s047k9wh6aspppnrzwaxbe.f71e3e84ab741db2c5a8d20df07ee098;Path=/;Secure;HttpOnly Expires: Thu, 01 Jan 1970 00:00:00 GMT X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Permitted-Cross-Domain-Policies: master-only X-Content-Type-Options: nosniff Content-Security-Policy-Report-Only: default-src 'none'; report-uri /post/cspreport/ Cache-Control: no-cache, no-store, no-transform Content-Type: text/plain *Connection: keep-alive* Set-Cookie: BIGipServerpool_sticky=111834251.3879.; path=/ Vary: Accept-Encoding Header name X-Forwarded-SSL - Header true Header name X-Forwarded-For - Header 139.112.144.209 Header name User-Agent - Header curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5 *Header name Connection* * - Header keep-alive* Header name Accept - Header */* Header name Host - Header whereever.no * This one hangs* * Jetty 8 (through big ip) * ➜ tmp curl -i https://whereever.no HTTP/1.0 200 Connection
Re: [jetty-users] Upgrading to Jetty 9.1
I just pushed a fix for #426870, can you try it out ? Thanks, Simone! Just gave it a shot after building from source. It works perfectly now. I tried using the snapshot repo first, but apparently that is only built once a day. There is something I cant really understand, though - why the heck does jetty interpret the request coming from big ip as a http 1.0 request? My clients, both my browser and curl use http 1.1 - what could make jetty believe it's a 1.0 request? Actually, I'm using a proxy (which only supports http 1.0 it turns out ...), but this is https (using Connect), so the 1.1 request reaches the big ip. In addition the response from big ip clearly states it's a 1.1 request. BTW - I attached to the actual jvm behind the load balancer, and looked at the ServletRequest in ServletHandler.java. It tells me its a 1.0 request. Where is the jetty code that chooses to interpret the request as 1.0, 1.1 etc Unfortunately I'm struggeling to get access to run a tcpdump - but should get that in the next few days Stefan ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Upgrading to Jetty 9.1
I managed to capture the bytes byte array in HttpVersion.lookAheadGet(...) It clearly says version 1.0. I'll have to check the big ip config. Stefan 2014-01-29 Stefan Magnus Landrø stefan.lan...@gmail.com I just pushed a fix for #426870, can you try it out ? Thanks, Simone! Just gave it a shot after building from source. It works perfectly now. I tried using the snapshot repo first, but apparently that is only built once a day. There is something I cant really understand, though - why the heck does jetty interpret the request coming from big ip as a http 1.0 request? My clients, both my browser and curl use http 1.1 - what could make jetty believe it's a 1.0 request? Actually, I'm using a proxy (which only supports http 1.0 it turns out ...), but this is https (using Connect), so the 1.1 request reaches the big ip. In addition the response from big ip clearly states it's a 1.1 request. BTW - I attached to the actual jvm behind the load balancer, and looked at the ServletRequest in ServletHandler.java. It tells me its a 1.0 request. Where is the jetty code that chooses to interpret the request as 1.0, 1.1 etc Unfortunately I'm struggeling to get access to run a tcpdump - but should get that in the next few days Stefan -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Upgrading to Jetty 9.1
-Protection: 1; mode=block
X-Permitted-Cross-Domain-Policies: master-only
X-Content-Type-Options: nosniff
Content-Security-Policy-Report-Only: default-src 'none'; report-uri
/post/cspreport/
Cache-Control: no-cache, no-store, no-transform
Content-Type: text/plain
Set-Cookie: BIGipServerpool_sticky=95057035.3879.; path=/
Vary: Accept-Encoding
Header name Host
- Header whereever.no
Header name Accept
- Header */*
Header name X-Forwarded-For
- Header 139.112.144.209
Header name X-Forwarded-SSL
- Header true
*Header name Connection*
* - Header keep-alive*
Header name User-Agent
- Header curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
OpenSSL/0.9.8y zlib/1.2.5
Does not hang
*
Local test (not through big ip)
*
this is jetty 8, but it looks similar for jetty 9 with regards to the
cunked transfer-encoding
$ curl -i -H Connection: keep-alive http://localhost:12345/whereever
HTTP/1.1 200 OK
X-MiniProfiler-Ids: [c9172169-755c-4bc2-a03d-9049e2b77e95]
Set-Cookie:
SESSION_COOKIE=f71e3e84ab741db2c5a8d20df07ee098r6navchnwslj1xn8vwlkrqoq2.f71e3e84ab741db2c5a8d20df07ee098;Path=/;Secure;HttpOnly
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Permitted-Cross-Domain-Policies: master-only
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
Content-Security-Policy-Report-Only: default-src 'none'; report-uri
/post/cspreport/
Cache-Control: no-cache, no-store, no-transform
Content-Type: text/plain
*Transfer-Encoding: chunked*
Header name Host
- Header localhost:12345
Header name Accept
- Header */*
Header name Connection
- Header keep-alive
Header name User-Agent
- Header curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
2014-01-28 Stefan Magnus Landrø stefan.lan...@gmail.com
Now new infrastructure, so this is definitely triggered by upgrading
jetty. However, the actual issue might be caused by new behaviour in jetty
triggering a bug in big ip.
Stefan
2014-01-28 lord.bud...@gmail.com
Stefan,
You said this was an 8.x to 9.x upgrade, so if the F5 was existing, it
shouldn't be an issue unless there are infrastructure changes at the same
time for upgrade. We use F5 and the only time we have seen something
similar was where a perimeter f/w was dropping an established connection
(due to inactivity) within the keep alive time. When the f/w does that
the browser does not know the connection it has is stuffed.
tcpdump is the best approach.
On 28 January 2014 08:45, Stefan Magnus Landrø
stefan.lan...@gmail.comwrote:
Thanks, Simone! I'm afraid I have to agree with you - this probably
won't fix my issue. I'll do some tcpdumping in the next few days - I'll
keep you posted. This might as well turn out being a f5 big ip issue.
Stefan
2014-01-27 Simone Bordet sbor...@intalio.com
Hi,
On Fri, Jan 24, 2014 at 9:36 PM, lord.bud...@gmail.com wrote:
Good find and a _critical_ bug in my view.
A change that came with 9.0 as it was this in 8.x :-
_header.put(CONNECTION_KEEP_ALIVE);
if (connection!=null)
{
_header.setPutIndex(_header.putIndex()-2);
_header.put((byte)',');
_header.put(connection.toString().getBytes());
_header.put(CRLF);
}
which had less logic, shorter lines... Yes, it copied 2 more bytes
than it
needed to but I would prefer less logic/shorter code over saving 2
bytes.
To fix this, you could _try_ turning off one connect on the f5 if you
don't
need it for other reasons.
We are also behind an F5, and are just about to start looking at
moving from
8.x to 9.x. ... so thanks ... will raise on support.
I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=426739 and fixed
it.
Note that this is a corner case that should happen very rarely, only
when the Connection header gets some custom value that is not
close or upgrade or keep-alive.
Therefore, I am dubious that the original problem (curl hanging for
chunked responses) is fixed by this fix.
Let us know if that is the case, though.
--
Simone Bordet
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty CometD experts.
Intalio, the modern way to build business applications.
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
--
BEKK Open
http://open.bekk.no
TesTcl - a unit test framework for iRules
http://testcl.com
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org
Re: [jetty-users] Upgrading to Jetty 9.1
Thanks, Simone! I'm afraid I have to agree with you - this probably won't
fix my issue. I'll do some tcpdumping in the next few days - I'll keep you
posted. This might as well turn out being a f5 big ip issue.
Stefan
2014-01-27 Simone Bordet sbor...@intalio.com
Hi,
On Fri, Jan 24, 2014 at 9:36 PM, lord.bud...@gmail.com wrote:
Good find and a _critical_ bug in my view.
A change that came with 9.0 as it was this in 8.x :-
_header.put(CONNECTION_KEEP_ALIVE);
if (connection!=null)
{
_header.setPutIndex(_header.putIndex()-2);
_header.put((byte)',');
_header.put(connection.toString().getBytes());
_header.put(CRLF);
}
which had less logic, shorter lines... Yes, it copied 2 more bytes than
it
needed to but I would prefer less logic/shorter code over saving 2 bytes.
To fix this, you could _try_ turning off one connect on the f5 if you
don't
need it for other reasons.
We are also behind an F5, and are just about to start looking at moving
from
8.x to 9.x. ... so thanks ... will raise on support.
I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=426739 and fixed it.
Note that this is a corner case that should happen very rarely, only
when the Connection header gets some custom value that is not
close or upgrade or keep-alive.
Therefore, I am dubious that the original problem (curl hanging for
chunked responses) is fixed by this fix.
Let us know if that is the case, though.
--
Simone Bordet
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty CometD experts.
Intalio, the modern way to build business applications.
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
--
BEKK Open
http://open.bekk.no
TesTcl - a unit test framework for iRules
http://testcl.com
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] Upgrading to Jetty 9.1
Hi there, We're in the process of upgrading to jetty 9.1 from latest jetty 8. Our app servers sit behind a F5 Big Ip load balancer, and after upgrading to 9.1, requests to resources that produce responses with Transfer-Encding: chunked, the request from the client (e.g. curl) hang for like 30 seconds due to what seems to be our connection keep-alive timeout. What could be causing this issue? Any pointers would be appreciated, Cheers, Stefan ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Upgrading to Jetty 9.1
Just came across this code in HttpGenerator.java - the
header.put(CONNECTION_KEEP_ALIVE,0,CONNECTION_CLOSE.length-2);
looks very much like a bug to me:
else if (keep_alive)
{
if (connection==null)
header.put(CONNECTION_KEEP_ALIVE);
else
{
header.put(CONNECTION_KEEP_ALIVE,0,CONNECTION_CLOSE.length-2);
header.put((byte)',');
header.put(StringUtil.getBytes(connection.toString()));
header.put(CRLF);
}
}
2014/1/24 Stefan Magnus Landrø stefan.lan...@gmail.com
Hi there,
We're in the process of upgrading to jetty 9.1 from latest jetty 8.
Our app servers sit behind a F5 Big Ip load balancer, and after upgrading
to 9.1, requests to resources that produce responses with Transfer-Encding:
chunked, the request from the client (e.g. curl) hang for like 30 seconds
due to what seems to be our connection keep-alive timeout.
What could be causing this issue?
Any pointers would be appreciated,
Cheers,
Stefan
--
BEKK Open
http://open.bekk.no
TesTcl - a unit test framework for iRules
http://testcl.com
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] [Jetty 8] Deadlock in JDBCSessionManager
Thanks! Great! 2014/1/13 Jan Bartel j...@intalio.com Stefan, As part of some changes for the mongo session manager, the sync block was removed from JDBCSessionManager.invalidateSession(String) in jetty-9: https://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/diff/jetty-server/src/main/java/org/eclipse/jetty/server/session/JDBCSessionManager.java?id=092c53b335c6ca8aa49a20698faf008d0469dbf4 cheers Jan On 14 January 2014 00:03, Stefan Magnus Landrø stefan.lan...@gmail.com wrote: Hi there, We're currently experiencing a deadlock in the JDBCSessionManager in latest jetty 8. There lots of synchronization code, which in addition to cause this deadlock, also performs really slow, since there are lots of synchronized blocks around jdbc calls. Has this been fixed in jetty 9? Anyone else seen this? Stefan -- Found one Java-level deadlock: = qtp235217511-3361: waiting to lock monitor 0x0992e268 (object 0xc4f29a38, a org.eclipse.jetty.server.session.JDBCSessionManager), which is held by qtp235217511-136 qtp235217511-136: waiting to lock monitor 0x09e027e8 (object 0xc4e3aaa8, a java.util.HashSet), which is held by qtp235217511-128 qtp235217511-128: waiting to lock monitor 0x0992e268 (object 0xc4f29a38, a org.eclipse.jetty.server.session.JDBCSessionManager), which is held by qtp235217511-136 Java stack information for the threads listed above: === qtp235217511-3361: at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:459) - waiting to lock 0xc4f29a38 (a no.posten.dpost.jetty.config.DpostJDBCSessionManager) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:75) at org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:312) at org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(SessionHandler.java:279) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:159) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:744) qtp235217511-136: at org.eclipse.jetty.server.session.JDBCSessionIdManager.removeSession(JDBCSessionIdManager.java:409) - waiting to lock 0xc4e3aaa8 (a java.util.HashSet) at org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(JDBCSessionManager.java:870) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:482) - locked 0xc4f29a38 (a no.posten.dpost.jetty.config.DpostJDBCSessionManager) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:75) at org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:312) at org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(SessionHandler.java:279) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:159) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135
[jetty-users] [Jetty 8] Deadlock in JDBCSessionManager
Hi there, We're currently experiencing a deadlock in the JDBCSessionManager in latest jetty 8. There lots of synchronization code, which in addition to cause this deadlock, also performs really slow, since there are lots of synchronized blocks around jdbc calls. Has this been fixed in jetty 9? Anyone else seen this? Stefan -- Found one Java-level deadlock: = qtp235217511-3361: waiting to lock monitor 0x0992e268 (object 0xc4f29a38, a org.eclipse.jetty.server.session.JDBCSessionManager), which is held by qtp235217511-136 qtp235217511-136: waiting to lock monitor 0x09e027e8 (object 0xc4e3aaa8, a java.util.HashSet), which is held by qtp235217511-128 qtp235217511-128: waiting to lock monitor 0x0992e268 (object 0xc4f29a38, a org.eclipse.jetty.server.session.JDBCSessionManager), which is held by qtp235217511-136 Java stack information for the threads listed above: === qtp235217511-3361: at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:459) - waiting to lock 0xc4f29a38 (a no.posten.dpost.jetty.config.DpostJDBCSessionManager) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:75) at org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:312) at org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(SessionHandler.java:279) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:159) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:744) qtp235217511-136: at org.eclipse.jetty.server.session.JDBCSessionIdManager.removeSession(JDBCSessionIdManager.java:409) - waiting to lock 0xc4e3aaa8 (a java.util.HashSet) at org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(JDBCSessionManager.java:870) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:482) - locked 0xc4f29a38 (a no.posten.dpost.jetty.config.DpostJDBCSessionManager) at org.eclipse.jetty.server.session.JDBCSessionManager.getSession(JDBCSessionManager.java:75) at org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:312) at org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(SessionHandler.java:279) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:159) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at
[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
Re: [jetty-users] Default error handling in jetty
Great stuff. We ended up subclassing ErrorPageErrorHandler, removing
stacktraces and the powered by jetty line etc.
Thanks,
Stefan
On 6 December 2011 01:51, Jan Bartel j...@intalio.com wrote:
Hi Stefan,
The ErrorPageErrorHandler, which is used by webapps, is a subclass of
ErrorHandler. If you don't wish any exception stacks shown in the
message, you can call setShowStacks(false) (or configure that in the
context's xml descriptor). Then, if you're not happy with just
registering pages with it, you could always replace the
ErrorPageErrorHandler class with one you've customized, again setting
that up on your webapp either in code or in xml. The code you refer
to will only execute if the context has no ErrorHandler, and the
Server has no ErrorHandler associated with it (which is yet another
avenue to customize your error handling - call server.addtBean(new
MySpecialErrorHandler()).
I think attending to these type of considerations is part of the
process of hardening up a web server installation for production, and
I think that Jetty gives you plenty of avenues to do that.
That said, I do wish sometimes that the ErrorHandler class didn't
include the Powered by Jetty line, as we sometimes get some strange,
irate emails from folks who unbeknownst to us and them use a poorly
configured service that is using Jetty :)
cheers
Jan
On 5 December 2011 23:47, Stefan Magnus Landrø stefan.lan...@gmail.com
wrote:
Hi there,
Whenever webapps deployed to jetty fail, one gets the message from the
exception set in the status line:
stefan landro@mac-stefanl:~/tmp $ wget -S http://localhost:8080/test
--2011-12-05 09:02:05-- http://localhost:8080/test
Resolving localhost... 127.0.0.1, ::1, fe80::1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response...
HTTP/1.1 500 My detailed exception Message
This is quite unfortunate, since such an exception message might leak
lots
of information about the application to a bad guy.
In addition, if for some reason the custom error handling in your web app
(error-page etc in web.xml) fails, jetty returns a default error page
(see
code below), leaking even more details about the exception (the entire
stack) in addition to the Powered by Jetty line, providing the bad guy
with even more details.
Wouldn't it make sense to remove this functionality from jetty?
Cheers,
Stefan
org.eclipse.jetty.server.Response.java (line 310):
writer.write(html\nhead\nmeta http-equiv=\Content-Type\
content=\text/html;charset=ISO-8859-1\/\n);
writer.write(titleError );
writer.write(Integer.toString(code));
writer.write(' ');
if (message==null)
message=HttpStatus.getMessage(code);
writer.write(message);
writer.write(/title\n/head\nbody\nh2HTTP ERROR: );
writer.write(Integer.toString(code));
writer.write(/h2\npProblem accessing );
writer.write(uri);
writer.write(. Reason:\npre);
writer.write(message);
writer.write(/pre);
writer.write(/p\nhr /ismallPowered by Jetty:///small/i);
for (int i= 0; i 20; i++)
writer.write(\n);
writer.write(\n/body\n/html\n);
--
BEKK Open
http://open.bekk.no
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
--
BEKK Open
http://open.bekk.no
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] Default error handling in jetty
Hi there,
Whenever webapps deployed to jetty fail, one gets the message from the
exception set in the status line:
stefan landro@mac-stefanl:~/tmp $ wget -S http://localhost:8080/test
--2011-12-05 09:02:05-- http://localhost:8080/test
Resolving localhost... 127.0.0.1, ::1, fe80::1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response...
HTTP/1.1 500 My detailed exception Message
This is quite unfortunate, since such an exception message might leak lots
of information about the application to a bad guy.
In addition, if for some reason the custom error handling in your web app
(error-page etc in web.xml) fails, jetty returns a default error page
(see code below), leaking even more details about the exception (the entire
stack) in addition to the Powered by Jetty line, providing the bad guy
with even more details.
Wouldn't it make sense to remove this functionality from jetty?
Cheers,
Stefan
org.eclipse.jetty.server.Response.java (line 310):
writer.write(html\nhead\nmeta http-equiv=\Content-Type\
content=\text/html;charset=ISO-8859-1\/\n);
writer.write(titleError );
writer.write(Integer.toString(code));
writer.write(' ');
if (message==null)
message=HttpStatus.getMessage(code);
writer.write(message);
writer.write(/title\n/head\nbody\nh2HTTP ERROR: );
writer.write(Integer.toString(code));
writer.write(/h2\npProblem accessing );
writer.write(uri);
writer.write(. Reason:\npre);
writer.write(message);
writer.write(/pre);
writer.write(/p\nhr /ismallPowered by Jetty:///small/i);
for (int i= 0; i 20; i++)
writer.write(\n);
writer.write(\n/body\n/html\n);
--
BEKK Open
http://open.bekk.no
___
jetty-users mailing list
jetty-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty Block IP based on visits
If you prefer servlet filters to jetty handlers, you could of course use that instead. Btw, users coming from behind an http proxy often use the same ip address. In addition, these same proxies often use several ip addresses. Cheers, Stefan On 5 December 2011 09:33, Thomas Becker tbec...@intalio.com wrote: Hi Cheney, jetty doesn't support this out of the box, no. But you can deal with it yourself by for example writing a custom handler (http://wiki.eclipse.org/ **Jetty/Howto/Write_Jetty_**Handlerhttp://wiki.eclipse.org/Jetty/Howto/Write_Jetty_Handler) which counts the requests per IP per hour/day and respond with an error page if the configured limit has been reached. If you're expecting a huge amount of requests be careful on how you track requests as this might need a big amout of memory depending on how you count/store the requests from the last day for example. Cheers, Thomas On 12/5/11 7:57 AM, Xin Chen wrote: Hi, Can you Jetty do this? Specifying the maximum request e.g. 1000 per day or per hour, for certain IP. If that IP reaches the limit, Jetty will show them error message etc. Thanks, cheney __**_ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/**mailman/listinfo/jetty-usershttps://dev.eclipse.org/mailman/listinfo/jetty-users -- thomas becker tbec...@intalio.com http://webtide.com / http://intalio.com (the folks behind jetty and cometd) __**_ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/**mailman/listinfo/jetty-usershttps://dev.eclipse.org/mailman/listinfo/jetty-users -- BEKK Open http://open.bekk.no ___ jetty-users mailing list jetty-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/jetty-users
