Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CometD makes overkill of requests #54

Closed
bhorvat opened this issue Jan 19, 2013 · 10 comments
Closed

CometD makes overkill of requests #54

bhorvat opened this issue Jan 19, 2013 · 10 comments

Comments

@bhorvat
Copy link

bhorvat commented Jan 19, 2013

I keep seeing strange message in the log files of my webapp.

127.0.0.1 - - [15/Jan/2013:23:00:53 +0000] "POST /cometd/connect HTTP/1.1" 200 147

This message is keep appearing in there and for the last few days I have seen in more then 20000 times in one hour so it managed to put my CPU to 100 utilization. Does anyone have idea what this is about?

If I try to go to that address it throw a 400 Unknown Bayeux Transport Exception

@uklance
Copy link
Owner

uklance commented Jan 19, 2013

Under the hood, tapestry-cometd is using the CometD integration in atmosphere [1], and an instance of
org.atmosphere.cometd.CometdServlet is created. Depending on what your servlet container supports, atmosphere will choose one of the following methods: WebSockets, Server Side Events (SSE), Long-Polling, HTTP Streaming (Forever frame) and JSONP. Based on your logging, I am guessing that Long-Polling has been chosen. Take a look at the supported servers table [2] to see what your servlet container supports.

Normally, the CometD servlet can be configured via init-params [3]. In tapestry-cometd, this can be configured in the AppModule [4]. I also have an outstanding issue in tapestry-cometd to support custom clientside configuration [5].

So, I suggest you pick a servlet container that supports your push method of choice and ask any further questions on the atmosphere mailing list. If you require custom client configuration [5] let me know and I can provide a fix and release a new version of tapestry-cometd.

[1] https://github.com/Atmosphere/atmosphere
[2] https://github.com/Atmosphere/atmosphere/wiki/Supported-WebServers-and-Browsers
[3] http://cometd.org/documentation/2.x/cometd-java/server/configuration
[4] https://github.com/uklance/tapestry-cometd/wiki/Configuring-the-CometD-Servlet
[5] #12

@bhorvat
Copy link
Author

bhorvat commented Jan 19, 2013

Ok I see what you mean and I will go to the atmosphere mailing list to check with them however if I try to go to that address it throw a 400 Unknown Bayeux Transport Exception. Could this indicate that something is not configured correctly?

In one of the examples above I found

  The org.cometd.server.CometdServlet must be defined and mapped in web.xml, or otherwise the server will not be able to interpret the Bayeux protocol.
  It is normally mapped on /cometd/*, but you can change the mapping url-pattern at your wish.

Does this mean that something should be configured in my app (or tapestry-cometd maybe)?

Thanks for fast reply

@uklance
Copy link
Owner

uklance commented Jan 19, 2013

tapestry-cometd does a little trick so that you don't need to configure the CometDServlet in web.xml. A HTTPServletRequestFilter (managed by tapestry) is configured to handle any requests for "/cometd/*". The servlet has no idea that it was instantiated by tapestry and not directly through web.xml.

http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/HttpServletRequestFilter.html
https://github.com/uklance/tapestry-cometd/blob/master/src/main/java/org/lazan/t5/cometd/web/ServletHttpServletRequestFilter.java
https://github.com/uklance/tapestry-cometd/blob/master/src/main/java/org/lazan/t5/cometd/web/CometdHttpServletRequestFilter.java

@bhorvat
Copy link
Author

bhorvat commented Jan 19, 2013

I was expecting (hopping) for something like that. So if I receive an Unknown Bayeux Transport Exception would this indicated that Bayeux Transport is not correctly mapped to the url?

@uklance
Copy link
Owner

uklance commented Jan 19, 2013

No, it means that you are hitting /cometd/* with an unexpected request. I'm guessing that atmosphere/cometd expects a POST request with some headers/parameters etc set. By hitting /cometd/ directly in your browser, you are sending an empty GET request which is unexpected.

@uklance
Copy link
Owner

uklance commented Jan 19, 2013

@bhorvat
Copy link
Author

bhorvat commented Jan 19, 2013

Ok I understand, then this has no barring on the overkill of the messages. Thanks, I have wrote on Atmosphere mailing lists and I am awaiting for their reply (I have also included the previous problem with the tomcat)

@bhorvat
Copy link
Author

bhorvat commented Jan 21, 2013

The problem seems to be passed on its own, so I am not really sure what was it about. However I did get one good idea that might have something to do with this so I am posting it here for future reference.

"please make sure there is no jetty-* class in the classpath as Atmosphere is detecting them and wrongly assume it is running on Jetty."

@bhorvat bhorvat closed this as completed Jan 21, 2013
@uklance
Copy link
Owner

uklance commented Jan 22, 2013

I'll have to check if tapestry-cometd has a jetty dependency. From memory it does and I may need to remove it.

@uklance
Copy link
Owner

uklance commented Jan 22, 2013

BTW: I think it might be valid for atmosphere / cometd to send thousands of requests to achieve push. In cases where the browser (or server) don't support websockets etc it will revert to polling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants