UnmodifiableMap with AcknowledgedMessagesClientEx tension (no security, no wildcards)
31 views
Skip to first unread message
sol
Dec 25, 2012, 5:04:04 AM12/25/12
to cometd...@googlegroups.com
Hi,
Could anyone please help with the following?
We use Cometd 2.4.3 with Acknowledgement extension.
Usually it works, but sometimes it stops delivering messages, and complains about "UnmodifiableMap" (trace below).
Once it starts failing, it only recovers after a server restart (there's no need to restart the browser).
BTW it usually happens if I leave the application running during lunch, during which I don't send any messages (but my log shows that long polling kept working, reconnecting every minute or so).
I searched this forum for "UnmodifiableMap" but saw only 2 mentions, that don't seem relevant:
1) Comend Security issues - but I didn't secure my application
2) Wildcards in channel names - but I register to a hard-coded channel, no wildcards
Is there please any record of this phenomenon?
And what, in general, could even cause the Map to become UnmodifiableMap....? From a quick naiive look at AcknowledgedMessagesClientExtension, it should be a simple HashMap...
Thanks very much.
Technical details:
- cometd version 2.4.3
- clients: java and javascript
- Stack trace:
5026862 [http-nio-80-exec-9] INFO org.cometd.bayeux.server.ServerSession - Exception while invoking extension org.cometd.server.ext.AcknowledgedMessagesClientExtension@774f492e
java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableMap.put(Collections.java:1342)
at org.cometd.server.ext.AcknowledgedMessagesClientExtension.sendMeta(AcknowledgedMessagesClientExtension.java:140)
at org.cometd.server.ServerSessionImpl.notifySendMeta(ServerSessionImpl.java:696)
at org.cometd.server.ServerSessionImpl.extendSendMeta(ServerSessionImpl.java:686)
at org.cometd.server.BayeuxServerImpl.extendReply(BayeuxServerImpl.java:917)
at org.cometd.server.transport.LongPollingTransport.handle(LongPollingTransport.java:411)
at org.cometd.server.CometdServlet.service(CometdServlet.java:181)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:271)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:306)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:166)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Could anyone please help with the following?
We use Cometd 2.4.3 with Acknowledgement extension.
Usually it works, but sometimes it stops delivering messages, and complains about "UnmodifiableMap" (trace below).
Once it starts failing, it only recovers after a server restart (there's no need to restart the browser).
BTW it usually happens if I leave the application running during lunch, during which I don't send any messages (but my log shows that long polling kept working, reconnecting every minute or so).
I searched this forum for "UnmodifiableMap" but saw only 2 mentions, that don't seem relevant:
1) Comend Security issues - but I didn't secure my application
2) Wildcards in channel names - but I register to a hard-coded channel, no wildcards
Is there please any record of this phenomenon?
And what, in general, could even cause the Map to become UnmodifiableMap....? From a quick naiive look at AcknowledgedMessagesClientExtension, it should be a simple HashMap...
Thanks very much.
Technical details:
- cometd version 2.4.3
- clients: java and javascript
- Stack trace:
5026862 [http-nio-80-exec-9] INFO org.cometd.bayeux.server.ServerSession - Exception while invoking extension org.cometd.server.ext.AcknowledgedMessagesClientExtension@774f492e
java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableMap.put(Collections.java:1342)
at org.cometd.server.ext.AcknowledgedMessagesClientExtension.sendMeta(AcknowledgedMessagesClientExtension.java:140)
at org.cometd.server.ServerSessionImpl.notifySendMeta(ServerSessionImpl.java:696)
at org.cometd.server.ServerSessionImpl.extendSendMeta(ServerSessionImpl.java:686)
at org.cometd.server.BayeuxServerImpl.extendReply(BayeuxServerImpl.java:917)
at org.cometd.server.transport.LongPollingTransport.handle(LongPollingTransport.java:411)
at org.cometd.server.CometdServlet.service(CometdServlet.java:181)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:271)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:306)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:166)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Simone Bordet
Dec 27, 2012, 6:41:52 AM12/27/12
to cometd-users
Hi,
On Tue, Dec 25, 2012 at 11:04 AM, sol <solm...@gmail.com> wrote:
> Hi,
>
> Could anyone please help with the following?
> We use Cometd 2.4.3 with Acknowledgement extension.
> Usually it works, but sometimes it stops delivering messages, and complains
> about "UnmodifiableMap" (trace below).
> Once it starts failing, it only recovers after a server restart (there's no
> need to restart the browser).
> BTW it usually happens if I leave the application running during lunch,
> during which I don't send any messages (but my log shows that long polling
> kept working, reconnecting every minute or so).
>
> I searched this forum for "UnmodifiableMap" but saw only 2 mentions, that
> don't seem relevant:
> 1) Comend Security issues - but I didn't secure my application
> 2) Wildcards in channel names - but I register to a hard-coded channel, no
> wildcards
>
> Is there please any record of this phenomenon?
> And what, in general, could even cause the Map to become
> UnmodifiableMap....? From a quick naiive look at
> AcknowledgedMessagesClientExtension, it should be a simple HashMap...
> Thanks very much.
I've never seen this error.
Seems like a /meta/connect response is sent twice, which should never happen.
I see you're using Tomcat, what exact version ?
Do you have this problem with Jetty too ?
I ask because Tomcat had (have ?) problems in handling asynchronous
requests and one common problem was an extra dispatch for the same
request which would lead to the problem you are experiencing.
Try Jetty and let us know if the problem is gone.
Simon
--
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
On Tue, Dec 25, 2012 at 11:04 AM, sol <solm...@gmail.com> wrote:
> Hi,
>
> Could anyone please help with the following?
> We use Cometd 2.4.3 with Acknowledgement extension.
> Usually it works, but sometimes it stops delivering messages, and complains
> about "UnmodifiableMap" (trace below).
> Once it starts failing, it only recovers after a server restart (there's no
> need to restart the browser).
> BTW it usually happens if I leave the application running during lunch,
> during which I don't send any messages (but my log shows that long polling
> kept working, reconnecting every minute or so).
>
> I searched this forum for "UnmodifiableMap" but saw only 2 mentions, that
> don't seem relevant:
> 1) Comend Security issues - but I didn't secure my application
> 2) Wildcards in channel names - but I register to a hard-coded channel, no
> wildcards
>
> Is there please any record of this phenomenon?
> And what, in general, could even cause the Map to become
> UnmodifiableMap....? From a quick naiive look at
> AcknowledgedMessagesClientExtension, it should be a simple HashMap...
> Thanks very much.
Seems like a /meta/connect response is sent twice, which should never happen.
I see you're using Tomcat, what exact version ?
Do you have this problem with Jetty too ?
I ask because Tomcat had (have ?) problems in handling asynchronous
requests and one common problem was an extra dispatch for the same
request which would lead to the problem you are experiencing.
Try Jetty and let us know if the problem is gone.
Simon
--
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
sol
Jan 7, 2013, 12:05:27 PM1/7/13
to cometd...@googlegroups.com
Thanks for this reply.
We have tomcat 7.0.29. So far it wasn't reproduced on my Jetty (which I only have for tests).
If it's a Tomcat "extra dispatch" problem - is there any workaround? E.g. some easy way to tell cometD to ignore such duplicates?
(I understand cometD is not to blame at all, but I'm looking for any way that would make it work without waiting for Tomcat fixes).
Thanks very much.
We have tomcat 7.0.29. So far it wasn't reproduced on my Jetty (which I only have for tests).
If it's a Tomcat "extra dispatch" problem - is there any workaround? E.g. some easy way to tell cometD to ignore such duplicates?
(I understand cometD is not to blame at all, but I'm looking for any way that would make it work without waiting for Tomcat fixes).
Thanks very much.
Reply all
Reply to author
Forward
0 new messages