Re: Distributable contexts and non-serializable session attributes
2011/7/10 Rainer Jung rainer.j...@kippdata.de:
I implemented an addition to DeltaManager which allows to filter which
session attributes actually get replicated (not yet committed).
This is useful, because many applications
- use non-serializable session attributes, so
it is not possible to simply replicate everything
- do not actually need everything replicated, because they
can bootstrap all they need from a login context if a filter
detects, that a failover has happened.
In these cases it can also help to reduce replication traffic a lot.
Unfortunately I stu,bled into some code in StandardSession:
public void setAttribute(String name, Object value, boolean notify) {
...
if ((manager != null) manager.getDistributable()
!(value instanceof Serializable))
throw new IllegalArgumentException
(sm.getString(standardSession.setAttribute.iae, name));
...
}
This means if you enable distributable, then you can no longer set any
non-serializable session attribute. The code is not recent, it goes back
to at least TC 3.3.
I understand, that it is helpful to devs being informed about
serialization/replication problems. But I think it is too strict to
enforce this in StandardSession whch is the base class of all our
cluster sessions and we always delegate to
StandardSession.setAttribute() after some cluster specific handling.
The SPEC says:
The container must accept objects that implement the Serializable interface.
- The container may choose to support storage of other designated
objects in the
HttpSession, such as references to Enterprise JavaBeans components and
transactions.
- Migration of sessions will be handled by container-specific facilities.
The distributed servlet container must throw an IllegalArgumentException for
objects where the container cannot support the mechanism necessary for
migration
of the session storing them.
(and some more in 7.7.2).
I think checking for serializability in StandardSession isn't good,
because AFAIK StandardSession isn't used by any mechanism Tomcat
supports to implement distributable.
And in DeltaSession I would like to have the check optional, i.e. only
check if the configuration wants the attribute to be replicated.
By default all attributes will be replicated as is today, but by
configuration one will be able to choose attributes to replicate using a
regexp against the attribute name.
Any remarks?
I think you are right and we can relax the requirement.
E.g. to delegate the check to some helper method that is overwritten
in DeltaSession or in other derived class.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Distributable contexts and non-serializable session attributes
On 10.07.2011 23:11, Filip Hanik - Dev Lists wrote: go ahead add it in, if you add in a flag to toggle the behavior, and the flag is defaulted to today's behavior. you're safe, and you give users an option Thanks for the feedback. I will go with Konstantin's suggestion of making it overwritable by any extension of StandardSession via putting the check in a protected method. The default impl will be unchanged, but DeltaSession can do something else. Again by default DeltaSession will just call super, but when the attribute replication filtering is on, it will only check if the attribute matches the filter. And now on to hacking ... Mark: no need to wait for that w.r.t. 7.0.19. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Distributable contexts and non-serializable session attributes
On 11.07.2011 13:41, Konstantin Kolinko wrote: 2011/7/10 Rainer Jung rainer.j...@kippdata.de: I think checking for serializability in StandardSession isn't good, because AFAIK StandardSession isn't used by any mechanism Tomcat supports to implement distributable. And in DeltaSession I would like to have the check optional, i.e. only check if the configuration wants the attribute to be replicated. By default all attributes will be replicated as is today, but by configuration one will be able to choose attributes to replicate using a regexp against the attribute name. Any remarks? I think you are right and we can relax the requirement. E.g. to delegate the check to some helper method that is overwritten in DeltaSession or in other derived class. Thanks, will do! Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Distributable contexts and non-serializable session attributes
On 11/07/2011 14:50, Rainer Jung wrote: On 10.07.2011 23:11, Filip Hanik - Dev Lists wrote: go ahead add it in, if you add in a flag to toggle the behavior, and the flag is defaulted to today's behavior. you're safe, and you give users an option Thanks for the feedback. I will go with Konstantin's suggestion of making it overwritable by any extension of StandardSession via putting the check in a protected method. The default impl will be unchanged, but DeltaSession can do something else. Again by default DeltaSession will just call super, but when the attribute replication filtering is on, it will only check if the attribute matches the filter. And now on to hacking ... Mark: no need to wait for that w.r.t. 7.0.19. ack. I'm still working my way through the issues I do need to fix for 7.0.19. Next stop, the TCK failure. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Distributable contexts and non-serializable session attributes
Rainer,
On 7/10/2011 3:38 PM, Rainer Jung wrote:
Unfortunately I stumbled into some code in StandardSession:
public void setAttribute(String name, Object value, boolean notify) {
...
if ((manager != null) manager.getDistributable()
!(value instanceof Serializable))
throw new IllegalArgumentException
(sm.getString(standardSession.setAttribute.iae, name));
...
}
This means if you enable distributable, then you can no longer set any
non-serializable session attribute. The code is not recent, it goes back
to at least TC 3.3.
I think checking for serializability in StandardSession isn't good,
because AFAIK StandardSession isn't used by any mechanism Tomcat
supports to implement distributable.
And in DeltaSession I would like to have the check optional, i.e. only
check if the configuration wants the attribute to be replicated.
By default all attributes will be replicated as is today, but by
configuration one will be able to choose attributes to replicate using a
regexp against the attribute name.
+1
-chris
signature.asc
Description: OpenPGP digital signature
Distributable contexts and non-serializable session attributes
I implemented an addition to DeltaManager which allows to filter which
session attributes actually get replicated (not yet committed).
This is useful, because many applications
- use non-serializable session attributes, so
it is not possible to simply replicate everything
- do not actually need everything replicated, because they
can bootstrap all they need from a login context if a filter
detects, that a failover has happened.
In these cases it can also help to reduce replication traffic a lot.
Unfortunately I stu,bled into some code in StandardSession:
public void setAttribute(String name, Object value, boolean notify) {
...
if ((manager != null) manager.getDistributable()
!(value instanceof Serializable))
throw new IllegalArgumentException
(sm.getString(standardSession.setAttribute.iae, name));
...
}
This means if you enable distributable, then you can no longer set any
non-serializable session attribute. The code is not recent, it goes back
to at least TC 3.3.
I understand, that it is helpful to devs being informed about
serialization/replication problems. But I think it is too strict to
enforce this in StandardSession whch is the base class of all our
cluster sessions and we always delegate to
StandardSession.setAttribute() after some cluster specific handling.
The SPEC says:
The container must accept objects that implement the Serializable interface.
- The container may choose to support storage of other designated
objects in the
HttpSession, such as references to Enterprise JavaBeans components and
transactions.
- Migration of sessions will be handled by container-specific facilities.
The distributed servlet container must throw an IllegalArgumentException for
objects where the container cannot support the mechanism necessary for
migration
of the session storing them.
(and some more in 7.7.2).
I think checking for serializability in StandardSession isn't good,
because AFAIK StandardSession isn't used by any mechanism Tomcat
supports to implement distributable.
And in DeltaSession I would like to have the check optional, i.e. only
check if the configuration wants the attribute to be replicated.
By default all attributes will be replicated as is today, but by
configuration one will be able to choose attributes to replicate using a
regexp against the attribute name.
Any remarks?
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Distributable contexts and non-serializable session attributes
go ahead add it in, if you add in a flag to toggle the behavior, and the flag is defaulted to today's behavior. you're safe, and you give
users an option
Filip
On 7/10/2011 1:38 PM, Rainer Jung wrote:
I implemented an addition to DeltaManager which allows to filter which
session attributes actually get replicated (not yet committed).
This is useful, because many applications
- use non-serializable session attributes, so
it is not possible to simply replicate everything
- do not actually need everything replicated, because they
can bootstrap all they need from a login context if a filter
detects, that a failover has happened.
In these cases it can also help to reduce replication traffic a lot.
Unfortunately I stu,bled into some code in StandardSession:
public void setAttribute(String name, Object value, boolean notify) {
...
if ((manager != null) manager.getDistributable()
!(value instanceof Serializable))
throw new IllegalArgumentException
(sm.getString(standardSession.setAttribute.iae, name));
...
}
This means if you enable distributable, then you can no longer set any
non-serializable session attribute. The code is not recent, it goes back
to at least TC 3.3.
I understand, that it is helpful to devs being informed about
serialization/replication problems. But I think it is too strict to
enforce this in StandardSession whch is the base class of all our
cluster sessions and we always delegate to
StandardSession.setAttribute() after some cluster specific handling.
The SPEC says:
The container must accept objects that implement the Serializable interface.
- The container may choose to support storage of other designated
objects in the
HttpSession, such as references to Enterprise JavaBeans components and
transactions.
- Migration of sessions will be handled by container-specific facilities.
The distributed servlet container must throw an IllegalArgumentException for
objects where the container cannot support the mechanism necessary for
migration
of the session storing them.
(and some more in 7.7.2).
I think checking for serializability in StandardSession isn't good,
because AFAIK StandardSession isn't used by any mechanism Tomcat
supports to implement distributable.
And in DeltaSession I would like to have the check optional, i.e. only
check if the configuration wants the attribute to be replicated.
By default all attributes will be replicated as is today, but by
configuration one will be able to choose attributes to replicate using a
regexp against the attribute name.
Any remarks?
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
