I've noticed some problems in using the REST API from clients that do not create (and maintain) HTTP sessions. The thing is that WebClient (class responsible for maintaining sessions, connection, etc) is bound to the http session and in case that you have a client that just make POST calls (without session maintenance), the API creates a new session, connection, producer, etc for every message sent. This is not a good thing from a resource point of view, but even bigger issue is the fact WebClient class never closes these resources, so the application is likely to exhaust all available resources after some time. The problem is that WebClient is created as HttpSessionListener and suppose to close resources on certain session events (passivate, value unbound, etc), but it is not registered in any of modules (and examples) distributed (and it can't be since is not designed to initialize properly in such use case).
I've made a quick fix by moving WebClient from session to servlet context and now everything looks fine (I've used session.getServletContext() instead of just "session" in appropriate method calls). I don't see particular motive for keeping WebClient in session instead of servlet context. Maybe for future authentication purposes (which is something I would like to tackle soon), but even in that case I would rather go with basic http authentication for each request than through session mechanism. Does anybody have any thoughts on this? I could do some refactoring here if we agree it is needed. -- Dejan Bosanac www.scriptinginjava.net
