Mikhail Baturov wrote:
Hi all,
We are trying to deploy our large CRM web-application migrated to
Portal(Jetspeed 2.1.3) - to Production, and expierencing a strange
non-regular exception with Portal session (we are using Spring Portlet MVC
also):
<snip/>
Looking at Spring sources, we can see this happens at 617 line
(underscored):
protected final Object getRenderCommand(RenderRequest request) throws
PortletException {
PortletSession session = request.getPortletSession(false);
if (session == null) {
throw new PortletSessionRequiredException("Could
not obtain portlet session");
}
Object command =
session.getAttribute(getRenderCommandSessionAttributeName());
if (command == null) {
throw new PortletSessionRequiredException("Could
not obtain command object from portlet session");
}
return command;
}
This exception happens accidentally at one of the production nodes (we
have a load-balancer there, but without cluster facilities) some time
after Jetspeed start and some load (5-10 simultaneous users), we can't
find an exact test-case to reproduce it. All we can state is that it
happens sometimes between Action and Render phase, when Render phase can't
find session (to get command and errors object from it) after Action phase
is completed.
But after it happened once at one of the node - it comes to inconsistent
state and this exception is thrown at any further request, untill we
restart the cluster.
I never experienced this issue before but it definitely seems something must be
wrong with the cluster
session sharing/handling.
For sure, request.getPortletSession(false) is allowed to return null if no
session exist yet, so technically there is
nothing wrong with this situation, but it seems weird no further requests will
recreate a new session.
But it is difficult to determine what's going on without debugging these kind
of tricky situations.
Maybe something is wrong with the (Tomcat) session handling and/or
configuration.
One thing to be aware of is that Jetspeed *itself* currently does *not* support
session replication, only sticky sessions.
If you do make use of session replication for your own webapp (not Jetspeed),
there could be some session coordination
problem from within Jetspeed, but again I cannot tell for sure without detailed
knowledge of your application configuration.
We are using oracle database for Jetspeed. Spring Portlet MVC - is the
lastest, 2.5.xx version (we had 2.xx earlier and updated but it didn't
help)
So in other words the issue is that Jetspeed deployed to multiple nodes
(just load-balancing and all of them point to the same Jetspeed Oracle
scheme) after start and some load - looses the Portal Session between
Action and Render phases during the same Action request processing, i.e. :
`request.getPortletSession(false)` from the subsequent Render phase -
fails returing null.
We haven't experienced it at our local development environments (i.e. at
single node environment). And we haven't got anything similar at Tomcat
(in production) before when we have our CRM as ordinary web-application,
so it can't be an issue with our code session logic.
Could you investigated it and tell why it can happen? Or what steps do you
suggest to do in order to discover the reason for it?
Thanks,
Regards,
Mikhail
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional
EU corporate and regulatory disclosures.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
