jetty-9

How to prevent consistent java pause pattern on Linux Mint

风格不统一 提交于 2019-12-01 17:49:15
问题 I have a Java app running on Linux Mint. EVERY minute, the program shows a very noticeable slow down -- A pause. The pause is a consistent 3 to 4 seconds. When we run further instances of the same program, they also pause 3 to 4 seconds each minute. Each program stops on a different second of the minute. latest update: After the last update (below) increasing the thread pool's thread count saw the GUI problem go away. After running for around ~40 hours we observed a thread leak in the Jetty

Too many Close_wait in jetty 9.0.3

牧云@^-^@ 提交于 2019-12-01 13:19:55
We have an application REST gateway deployed over jetty 9.0.3 server.For authentication and authorization of services deployed in jetty is taken care by apache commons-httpclient3.1. when there are huge number of concurrent threads hitting Rest gateway, lot of CLOSE_WAIT are piling up in REST gateway machine. Http connections which are opened for sending request to enabler(END POINT)are closed properly by calling releaseConnections method of apache commons. Please let me know how to handle these CLOSE_WAIT or any clues why connections are ending up in CLOSE_WAIT. The close_wait connections

Too many Close_wait in jetty 9.0.3

半城伤御伤魂 提交于 2019-12-01 10:38:21
问题 We have an application REST gateway deployed over jetty 9.0.3 server.For authentication and authorization of services deployed in jetty is taken care by apache commons-httpclient3.1. when there are huge number of concurrent threads hitting Rest gateway, lot of CLOSE_WAIT are piling up in REST gateway machine. Http connections which are opened for sending request to enabler(END POINT)are closed properly by calling releaseConnections method of apache commons. Please let me know how to handle

Jetty-9 warning: badMessage: 400 Illegal character

做~自己de王妃 提交于 2019-12-01 02:08:16
I am using jetty-9.2.2 with CometD-3.0.1. I am seeing below warning in my setup. It comes ~4,5 times in a day.: 2014-08-28 08:50:53.712:WARN:oejh.HttpParser:qtp607635164-15194: badMessage: 400 Illegal character for HttpChannelOverHttp@5946f125{r=1,a=IDLE,uri=-} There is no details that can be debugged from the warning message. I have already logged a request https://bugs.eclipse.org/bugs/show_bug.cgi?id=443049 to provide detailed warning. Meanwhile I want to know what is causing this warning? Can I ignore this or some messages are lost because of this? I had the same error, then found out that

Jetty - stand alone WebSocket server

痞子三分冷 提交于 2019-11-30 23:46:51
in these days I try to implement a WebSocket server by using Jetty. I've created a Jetty project called "WebSocketServer" as demo-base in the distribution of Jetty 9.2.0.v20140526 . After that, I write some codes to implement the WebSocket mechanism and export all codes to a war file to push it to the webapps folder of "WebSocketServer". When I java -jar ..<jetty.home>/start.jar , it is all workable. But, after I create a new connection to this WebSocket project, there are some error codes happened. java.lang.ClassCastException: org.eclipse.jetty.server.HttpConnection cannot be cast to org

Jetty WebSocket api vs the standard JSR 356 API

荒凉一梦 提交于 2019-11-30 09:04:44
Jetty 9 supports both it's own Jetty Websocket API as well as the standard JSR 356 API, for what I assume are historical reasons (Jetty's API precedes the final JSR 356 ). I've looked over the basic documentation of both APIs, as well as some examples. Both APIs seem fairly complete and rather similar. However, I need to choose one over the other for a new project I'm writing, and I'd like to avoid using an API that might be deprecated in the future or might turn out to be less feature-rich. So are there any important differences between the two except for the obvious fact that one is

Jetty startup delay due to scanning

有些话、适合烂在心里 提交于 2019-11-29 09:55:44
Context and setup information: Jetty 9 with the eclipse jetty plugin Spring 4.1.1.RELEASE with Spring Security 3.2.3 Spring Java Configuration (no web.xml) Problem description Starting jetty 9 is very slow in a project where Spring's JavaConfig is used to boot the Spring context instead of using a web.xml . Jetty seems to be doing nothing during a considerate amount of time. This occurs after the line: INFO:oejs.Server:main: jetty-9.2.3.v20140905 Jetty does start eventually, but takes very long to start up compared to a regular tomcat 7 distribution. Additional resources public class

Websocket JSR-356 fail with Jetty 9.4.1

[亡魂溺海] 提交于 2019-11-28 13:10:38
My current web server is embedded Jetty 9.1.5. It works well with JSR-356 to create websocket. These days, I am trying to upgrade to Jetty 9.4.1. Everything works nicely except websocket. My code like below: Embedded Jetty and Websocket libs: <dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-server</artifactId> <version>9.4.1.v20170120</version> </dependency> <dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-webapp</artifactId> <version>9.4.1.v20170120</version> </dependency> <dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-annotations<

Jetty startup delay due to scanning

戏子无情 提交于 2019-11-28 03:09:45
问题 Context and setup information: Jetty 9 with the eclipse jetty plugin Spring 4.1.1.RELEASE with Spring Security 3.2.3 Spring Java Configuration (no web.xml) Problem description Starting jetty 9 is very slow in a project where Spring's JavaConfig is used to boot the Spring context instead of using a web.xml . Jetty seems to be doing nothing during a considerate amount of time. This occurs after the line: INFO:oejs.Server:main: jetty-9.2.3.v20140905 Jetty does start eventually, but takes very

ECDHE cipher suites not supported on OpenJDK 8 installed on EC2 Linux machine

跟風遠走 提交于 2019-11-27 04:39:11
When starting jetty-distribution-9.3.0.v20150612 with openjdk 1.8.0_51 running on an EC2 Amazon Linux machine, is prints that all configured ECDHE suites are not supported. 2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported 2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported 2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 not supported 2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM