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

Recoursive implementation of push send method causes StackOverflowError in tomcat #439

Closed
BlindNW opened this Issue Mar 5, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@BlindNW

BlindNW commented Mar 5, 2018

I'm using this setup in my tomcat 8.5 app:

'org.jboss.weld.servlet', name: 'weld-servlet', version: '2.4.0.Final'
'org.omnifaces', name: 'omnifaces', version: '2.5.1'
'org.glassfish', name: 'javax.faces', version: '2.2.13'

I'm using socket component and here is what I've observed in logs of my application:

java.lang.StackOverflowError
        at java.util.ResourceBundle.getString(ResourceBundle.java:407)
        at org.apache.tomcat.util.res.StringManager.getString(StringManager.java:126)
        at org.apache.tomcat.util.res.StringManager.getString(StringManager.java:158)
        at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1224)
        at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.textStart(WsRemoteEndpointImplBase.java:1187)
        at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendStringByCompletion(WsRemoteEndpointImplBase.java:209)
        at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendStringByFuture(WsRemoteEndpointImplBase.java:197)
        at org.apache.tomcat.websocket.WsRemoteEndpointAsync.sendText(WsRemoteEndpointAsync.java:53)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:152)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        at org.omnifaces.cdi.push.SocketSessionManager.send(SocketSessionManager.java:161)
        ...

I've shortened the stacktrace above (it has a lot of send calls, and looks like even cutted by jvm as at the bottom is still SocketSessionManager.send).

I'm not shure what am I doing wrong but this recoursive implementation without any recoursion depth limit or sleeps betwen retries looks dangerous to me:

private void send(Session session, String text, Set<Future<Void>> results, int retries) {
		if (session.isOpen()) {
			try {
				results.add(session.getAsyncRemote().sendText(text));

				if (retries > 0 && logger.isLoggable(WARNING)) {
					logger.log(WARNING, format(WARNING_TOMCAT_WEB_SOCKET_BOMBED, retries));
				}
			}
			catch (IllegalStateException e) {
				if (Hacks.isTomcatWebSocketBombed(session, e)) {
					synchronized (session) {
						send(session, text, results, retries + 1);
					}
				}
				else {
					throw e;
				}
			}
		}
	}

Also, looks like in my case original public send method also sometimes blocks for a long time (when send finally works), and I can't protect from this, as public send returns set of Future objects, so in theory it should not block the caller thread, however, the recoursive retries still happen in caller thread...

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Mar 11, 2018

Member

Yup, that's an ugly hack. I'll look how to best improve it.

Member

BalusC commented Mar 11, 2018

Yup, that's an ugly hack. I'll look how to best improve it.

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Mar 11, 2018

Member

Fix is available in today's latest 3.1-SNAPSHOT.

Member

BalusC commented Mar 11, 2018

Fix is available in today's latest 3.1-SNAPSHOT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment