[
https://issues.apache.org/jira/browse/OFBIZ-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400132#comment-13400132
]
Jacques Le Roux commented on OFBIZ-4289:
----------------------------------------
I did not get what you mean by
{quote}
if everything works fine then there was no reason for keeping them in even if
they were not broken.
{quote}
What I know is that if you try to serialize them you get a NPE (from Tomcat)
because they can't be serialised. In other words it works in a non distributed
context but, as soon as you want to distribute, login out fails, because you
need to persist sessions.
On the other hands, I agree on this
{quote}
We should better check how they are used and when before setting them to null.
{quote}
But what will you do then: make them serializable? Or maybe rather change the
code which is *supposed* to use them...
{quote}
was not suggesting to add Serializable to OFBiz classes;
{quote}
I did not understand that. I was simply suggesting that developers may add
other Objects in session (than the ones we are concerned so far) that would be
non serialised, ignoring the issue with logout in distributed applications. But
they may want and be able to serialise them. With what you are suggesting this
will be hidden and will not let them cope with the issue they may ignore (this
is not an obvious issue before you stumble upon it, believe me). For instance
(I hope) nobody was aware of this issue before I found it.
{quote}
I was saying that, if the issue you are facing in distributable app mode is
that the session contains non serializable objects (e.g. "security" etc..)
then, instead of hardcoding the code in LoginWorker to null them, it would be
more elegant (impossible) to hook before the session is serialized and iterate
thru the objects in the session and null the ones that don't implement
Serializable. In this way, if the system is running a serializable Security
implementation, then it will be stored in the session even if in distributable
mode.
The code would be also cleaner (no need to add variables and special handling
in LoginWorker)
{quote}
This is going much further than expected. First we must know why those are put
in session, what is the need?
{quote}
hook before the session is serialized
{quote}
This is done by Tomcat (actually the implementation of
[ManagerBase|http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/session/ManagerBase.html]
used) and, if possible, I guess would need much more work than clarifying the
fact that those are really needed in session when login out...
> Login out on a cluster handled by DeltaManager causes a NPE
> -----------------------------------------------------------
>
> Key: OFBIZ-4289
> URL: https://issues.apache.org/jira/browse/OFBIZ-4289
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 4.0, Release Branch 09.04, Release Branch
> 10.04, Release Branch 11.04, SVN trunk
> Environment: Ubuntu
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Priority: Critical
> Labels: cluster, logout
> Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk
>
> Attachments: OFBIZ-4289_Login_out_on_a
> cluster_handled_by_DeltaManager_causes_a_NPE.patch, OFBIZ-4289_Login_out_on_a
> cluster_handled_by_DeltaManager_causes_a_NPE.patch, OFBIZ-4289_Login_out_on_a
> cluster_handled_by_DeltaManager_causes_a_NPE.patch, OFBIZ-4289_Login_out_on_a
> cluster_handled_by_DeltaManager_causes_a_NPE.patch, OFBIZ-4289_Login_out_on_a
> cluster_handled_by_DeltaManager_causes_a_NPE.patch, changeset_2510.diff
>
>
> It works locally but not on clusters. You simply get a NPE.
> h3. Problem
> * When we logout we cross an issue due to Tomcat sessions persistence.
> * Because we set distributable to true, to allow sessions failover,
> * and use and DeltaManager for replication.
> * Delegator and other main Classes (notably Dispatcher) are not
> serialized in OFBiz. This is the origin of the problem
> h3. Tried solutions
> By default DeltaManager save active sessions on disk. It uses a private
> String variable pathname for that (default to "SESSIONS.ser"). You can set it
> to null, to avoid session persistence, using a context.xml file in the
> WEB-INF folder with content like below. But I tried it in webtools app on
> staging qs001 (only) and it did not work (with distributable set to false).
> And we have no other means to set it from OFBiz (OOTB).
> {code}
> <Context>
> <Manager className="org.apache.catalina.session.DeltatManager"
> pathname="">
> </Manager>
> </Context>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
