Hi I have read all evidence until now and I think it is clear what's going on. I checked if the state could be serialized and it works, so my first theory was discarded.
At this point, the following facts are true: 1. If encryption is disabled, the problem dissapear. 2. If encryption is enabled and no org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET are set the problem is present. 3. If encryption is enabled and only org.apache.myfaces.SECRET is set the problem is present. 4. If encryption is enabled and org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET are set the problem dissapear. By default if no secret or mac secret is set MyFaces generate automatically one at startup. This works well when we have only one server running (that's the reason why we don't see it standalone), but does not work well when the application runs into a cluster like with GAE. Let's suppose we have two server, A and B. At start myfaces is initialized on server A and the session is generated. After some time the session is serialized to disk, and on a further request, serve B should handle the request. In that case, B should call initialization code and here is where the problem begins, during initialization another secret is generated without take into account the one in A. Later, since the secrets does not match, an ViewExpiredException is thrown, because it can't decode correctly with the key it was generated. The reason why both org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET should be set, is because we need to ensure the same secret is used on every request. Since we define the key on web.xml, a random one is no longer used and the problem dissapear. One possible option to make this one more user friendly is save the random org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET on session map, so when the session is restored, the right secret is always used. Note this is an enhancement, so the current behavior is valid. The problem with ajax seems to be by some reason the session is marked as invalid, so the full response is sent, but it is not clear why it happens. regards, Leonardo Uribe
