I have the following sitebricks servlet. Foo.get()
is accessible as a GET
at /foo/bar
. I deployed the servlet to GAE.
@Service
@At("/foo")
@Singleton
public class Foo {
@Get
@At("/bar")
public Reply<?> bar(Request<String> request, HttpSession session) {
// access request scoped HttpSession
}
}
If I understand sitebricks correctly, both Request and HttpSession are injected by sitebricks (potentially with the help of Guice). It will also ensure that the HttpSession is local to the current request. Concurrent requests will be executed on the same instance of Foo
since the class is annotated with @Singleton
(see Guice docs). But even with concurrent requests arriving on the same JVM, each invocation of bar()
will have it's own HttpSession based on the JSESSIONID passed in by the client. Are all those assumptions valid?
When running load tests against my app, I have noticed that at a very low rate the HttpSession passed in by sitebricks/Guice is null. I am troubleshooting this with Google's support at the moment. But apart from GAE - What could cause this from the perspective of sitebricks/Guice?
I found a code snippet that injects a Provider into the constructor. Does that mean I can/should get the HttpSession by calling Provider.get()
instead of letting sitebricks inject it as a method parameter?
Related Questions:
- Provider<HttpSession> not getting injected
- How to @Inject a HttpSession object in a service layer (DAO) class in GWT using Guice?
- Inject @SessionScoped value into filter with Guice
Updates
- I removed the HttpSession parameter from all the servlet methods like
bar
. I injected aProvider<HttpSession>
into the servlet and callprovider.get()
to get the session. The tests that I ran so far indicate that this is more reliable than gettingHttpSession
out of the parameters. That said, I am not sure if the session is provided by sitebricks or GAE itself. Is the HttpSession provided by the servlet container?