@Scheduled does not work on @ServerEndpoint deployed with per-connection lifecycle [SPR-10611]

[spring-projects-issues]

Nick Williams opened SPR-10611 and commented

I created the following class:

@ServerEndpoint(value = "/chat/{sessionId}",
        encoders = ChatMessageDecoderCodec.class,
        decoders = ChatMessageDecoderCodec.class,
        configurator = SpringConfigurator.class)
public class ChatEndpoint
{
    ...
    @Inject SessionRegistry sessionRegistry;
    @Inject ChatService chatService;
    ...
    @Scheduled(fixedDelay = 25_000L, initialDelay = 25_000L)
    public void sendPing()
    {
        log.info("Sending ping to WebSocket client.");
        try
        {
            this.wsSession.getBasicRemote()
                    .sendPing(ByteBuffer.wrap(ChatEndpoint.pongData));
        }
        catch(IOException e)
        {
            log.warn("Failed to send ping message to WebSocket client.", e);
        }
    }
    ...
    @PostConstruct
    public void initialize()
    {
        this.sessionRegistry.registerOnRemoveCallback(this::httpSessionRemoved);
    }
}

When I connect to the WebSocket connection, the @Inject dependencies get properly injected and the initialize method gets properly called. However, the @Scheduled method never executes. A @Scheduled method on a separate @Service executes just fine (so my scheduler/executor are configured correctly), but not the method on the endpoint.

This is likely to be a common use case. Pings need to be sent periodically to keep connections alive, and @Scheduled is the perfect way to do this. Whatever is keeping this from working should be resolved.

---

Affects: 4.0 M1

Issue Links:

• SpringConfigurator uses ListableBeanFactory method which is documented to be slow for EVERY new WebSocket connection [SPR-10605] #15234 SpringConfigurator uses ListableBeanFactory method which is documented to be slow for EVERY new WebSocket connection

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid that - at this point - @Scheduled methods do not work on instances that are being managed outside of Spring's own container, which is exactly the case here: Such connection-scoped WebSocket endpoints are being created through Spring's createBean method which does apply all initialization callbacks to the created instance but does not retain that instance within Spring's own lifecycle management. Instead, it's the WebSocket runtime releasing that endpoint instance based on its own lifecycle assumptions.

There may be ways to extend our @Scheduled support to such externally managed instances - if we can reliably expect a corresponding destroyBean callback to unregister the trigger when the externally managed instance has been released. We'll see what we can do in that respect for 4.0 M2.

Juergen

[spring-projects-issues]

Nick Williams commented

I wondered about that. What other features like @Scheduled don't work with createBean-created beans? It'd be nice to have a list of that to know if there are other areas that could possibly be improved. Maybe I can help improve this at some point in the next couple of months. I need to get ahead on my book chapters before I can devote the time, though.

For that matter, looking at createBean, initializeBean, configureBean, and autowireBean, none of them seem to add a bean to the container. I'm not suggesting that should change for these particular methods, but IS there a way to add a bean to the container programmatically (other than @Configuration/@Bean)? (Not suggestion that is a solution to this problem.)

As to some form of callback, what about an interface like the following:

public interface SelfDisposingBean
{
    void setDisposeCallback(DisposeCallback callback);
}

public interface DisposeCallback
{
    void destroyBean(SelfDisposingBean bean);
}

Beans implementing the SelfDisposingBean would have a callback set automatically during the bean post processing phase. When the bean determined it was ready to be disposed of it would call the callback's destroyBean method, which would trigger all the destroy actions on it. Unfortunately, there simply isn't a way for Spring to "know" when a bean is ready for disposal. It will always just have to be well-documented that it's up to the developer to reliably call the callback.

Spring could, as a protective measure, only apply features like @Scheduled on such beans if SelfDisposingBean was implemented. That would make it somewhat safer.

[spring-projects-issues]

Rossen Stoyanchev commented

@Scheduled works if the endpoint is deployed as a singleton. To deploy as a singleton, simply declare the @ServerEndpoint as a Spring bean. That said if you want a stateful endpoint, i.e. a new instance for each WebSocket session, then the issue is exactly as described above.

I've updated the title accordingly.

[spring-projects-issues]

Nick Williams commented

Rossen Stoyanchev, two questions:

1. You didn't answer my question, "What other features like @Scheduled don't work with createBean-created beans?" I can't find a list anywhere that details this. It's clear now that scheduling doesn't work with createBean-created beans. What else?
2. What did you think of my idea of the SelfDisposingBean, and letting @Scheduled (and other disabled features) work for non-singleton beans that implement SelfDisposingBean? It would have the advantage that it wouldn't automatically change existing behavior for non-singleton beans—developers would have to make the conscious effort to implement SelfDisposingBean in order for the behavior to change. setDisposeCallback should actually be registerDisposeCallback, so that multiple components (scheduling, etc.) can register to be notified when a non-singleton bean destroys itself.

[spring-projects-issues]

Nick Williams commented

Rossen Stoyanchev, can you answer my questions above? I'd love to do what's necessary to implement this, but I don't want to go to the trouble if y'all prefer the behavior to remain as-is. I've explored the code base and debugged the registration of @Scheduled methods, and I think it's going to be fairly easy to implement my idea (question #2).

[spring-projects-issues]

Rossen Stoyanchev commented

"What other features like @Scheduled don't work with createBean-created beans?"

I don't know the answer and I'm not aware of such a list. Such annotations are usually supported through a BeanPostProcessor, so one suggestion is to search for *AnnotationBeanPostProcessor.

What did you think of my idea of the SelfDisposingBean

Do you have a specific use case in mind? If you declare the server endpoint class in Spring configuration, it will be instantiated as a singleton (with full support for context services like @Scheduled), and as you know the SpringConfigurator will get this instance rather than calling createBean. I would imagine for things like @Scheduled, the singleton scope is a much better choice and perhaps the only feasible choice (would you really want to have @Scheduled on every endpoint instance otherwise?).

[spring-projects-issues]

Nick Williams commented

Okay. You make valid points. You can close this as "won't fix."

[spring-projects-issues]

Rossen Stoyanchev commented

Ok thanks.