Within a web application, you often need a state to create a session lifecycle. You may create a CDI named been with session scope, to keep track of some user data. Suppose, you have a JSF application. Assigned to your pages you might use named beans with request scope. If you need some session-wide info, you can use CDI:
@inject SessionBean mySessionBean
I moved an application which ran without known problems on GlassFish 3 to GlassFish 4. Everything worked fine, as long as I tested the app for myself. But using this app concurrent with other users, sometimes the app showed me a session timeout, could not restore a conversation or, in one case, showed me data of a concurrent user. It seemed, a SessionBean object of a different user had been injected to the request bean assigned to my request.
This issue might be in context with a memory leak of GlassFish in conjunction with Weld (CDI) [1]. I didn’t check, whether this is a real cause, or if there is a different issue with the CDI implementation, but updating Weld to version 2.0.5 solved the problem. Or exactly: Since this update I could not reproduce this problem.
Usually, updating a module for GlassFish 4 is quite easy:
- Stop GlassFish domain
- Replace the module (jar file) in GlassFishHome/glassfish/modules
- Restart GlassFish domain
As the time of writing, you may also update JSF to version 2.2.5.
Because some posts exists for updating special modules (Weld [2], JSF [3]), I only described the general procedure for updating a module. And never forget to double-check whether your your updated environment is working as expected before going productive.
[1] https://java.net/jira/browse/GLASSFISH-20928
[2] http://delabassee.com/blog/?p=286
[3] https://weblogs.java.net/blog/mriem/archive/2013/10/29/jsf-tip-29-update-your-jsf-version-glassfish
Read my Tutorial web development (with JSF).
Update: I recognized, [2] is not available sometimes. Try Weld Download at [4]
[4] http://weld.cdi-spec.org/download/
The latest Payara 4.1.152 has a number of patches in for issues like this and has upgraded to the latest Weld SP1. I would try on there and see if this is fixed.
Before I updated WELD and JSF, I recognized a smoothly increase of memory usage. When the problem happened, memory usage had became it’s maximum.
Beside that update, I tuned the memory usage of the JVM.
Admin console -> Configurations -> server-config -> JVM Settings -> JVM Options
I increased the maximum heap size -Xmx512m –> -Xmx4096m
inserted the parameter for a initial size: -Xms512m
and increased the max perm size: -XX:MaxPermSize=192m -> -XX:MaxPermSize=1024m
Beware of enough physical memory (at the machine with the parameters above: 8GByte)
I haven’t further investigated whether the update or the memory tuning or both in conjunction helped. But till now, the server runs without those problems.
Hi, im having same behavoiur on Glassfish 3.0.1 on Centos 6.5, no proxy. I updated weld following this guide http://www.andygibson.net/blog/quickbyte/updating-weld-in-glassfish-v3/ and now im monitoring the server to see if it happens again.
Thanks,
But the problem persist however the time to happen is greater that without this upgrade
Do you know more something else?
I sadly noticed the same. Before that upgrade (as described above), I faced the problem quite often.
After the upgrade, GlassFish run a couple of weeks until the same problem happened again. Then, I slightly changed the handling of conversations (might be the same using view or flow scope). After that, problem did not happen anymore, even though there is much traffic. But, it’s quite to early to say, that I solved this problem for the desired app. I guess, I have to observe the server some additional weeks.
However, if not really solved yet, it seems to be a lesser problem now.
I prepared a small application to show the change in my handling. But, I’m running out of time. I still haven’t finished my security trail. Maybe, I’m able to insert the conversation stuff before.
Hi,
We have been experiencing this behaviour for several months. We updated to Weld 2.0.5, Mojarra 2.2.6 and Tyrus (WebSocket-ri-archive-1.4).
Weld has improved the behaviour but, like you both said, It just happen again.
We have a multilevel sales platform and we have to re-start glass fish every two days because users can access ManagedBeans from others users either currently logged or already logged out.
I will try to describe the Facts we know in case the info is useful to solve the problem or at least get a work around.
Environment:
– The System is totally deployed on Amazon Cloud.
– Glassfish 4.0 updated to Weld 2.0.5, Mojarra 2.2.6 and Tyrus (WebSocket-ri-archive-1.4).
– JVM: OpenJDK 1.7.051
– LoadBalancer: ELB (Amazon).
When the platform starts behaving wrong the @Inject on a @SessionScope ManagedBean can result on:
– Delivery ManagedBean of current Context, which is good.
– Delivered ManagedBean of other currently logged IN user -> Fail
– Delivered ManagedBean of other currently logged OUT user -> Fail
The way we know if the user is currently logged or not is because we ask if the current context is not null.
E.g. :
@Named(“userSessionBean”)
@SessionScoped
public class UserSessionBean implements Serializable {
private User user;
public User getUser() {
if(!verifySession()){
System.out.println(user.getName()); // <— This user is different from the one that made the request
return null;
}
return user;
}
public boolean verifySession(){
ExternalContext ctx = FacesContext.getCurrentInstance().getExternalContext();
Object session = ctx.getSession(false);
return session != null;
}
}
And sometimes when a JSF page tries to render userSessionBean.user.name a null pointer exception is thrown.
The same when the invocation occurs from other ManagedBean, the returned user is indeed null.
Before coding the verifySession() method the occurrence of the Session Swapping occurred more frequently, now we can act when the given context is non existent. but when the given context is from other user currently logged there is no way to detect this behaviour.
Other fact is that when using a load balancer you are reusing connections. So 10 remote clients establish 10 connections with the load balancer and this manages all 10 connection using just one connection to glassfish.
Monitoring the null pointer exceptions thrown by the app. we might think the bug can affect only one httplistenner, and when it does, it starts swapping users/sessions from the same httplistenner thread. After a while all the httpListenners start to fail.
By now we have two alternatives to try to minimise the impact:
1) avoid using a load balancer
2) migrate from GF 4 to WildFly 8.0
We will publish the result as soon as we have them.
Please let us know if you have a similar environment or any work around or solution for this problem.
Please try on Payara http://www.payara.co/downloads which is a heavily patched version of GlassFish 4.1. If you see the problem raise an issue on http://www.github.com/Payara and we can investigate.
Hi Steve,
After updating Weld and JSF on GF4 plus increasing memory size, the server run without problems. And with GlassFish 4.1, I never faced this problem. Payara might be a good choice too, but GF is still used to develop the reference implementation of JSF.