Heads up on jetty/terracotta

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Heads up on jetty/terracotta

sharrissf
I took the latest version of jetty and added a root to a servlet and it just worked. So for those 
who are interested in clustering outside of session you should be good to go. I'll try to do a write up on the
steps when I get a free second.


Cheers,
Steven Harris

Director of Engineering




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Heads up on jetty/terracotta

jan_bartel
Hi Steven,

When you write it up, don't forget to post a link and I'll put it in the
Jetty wiki ;-)

Regarding sessions, because we're more familiar with Jetty code, we thought
as our first cut at the Terracotta session integration, we thought we'd
subclass our own SessionIdManager and SessionManager classes. That would
entail overcoming these 2 edge cases in the current code to accommodate
session replication:

  1. when a context is being taken out of service, the session map
     is cleared out.

  2. session scavenging (as described below).

How does the terracotta session stuff handle 1 and 2? In particular, how
do you handle session scavenging? For example, in the current Jetty code
we set a timer and iterate over the list of sessions to find ones that
have expired. In a clustered situation, that would cause all sessions
to be shared across all nodes, which is clearly not desirable :-)
How does TC handle that?

Also does terracotta sessions code handle session ids across cross-context
dispatches?

cheers
Jan




Steven Harris wrote:

> I took the latest version of jetty and added a root to a servlet and it
> just worked. So for those
> who are interested in clustering outside of session you should be good
> to go. I'll try to do a write up on the
> steps when I get a free second.
>
>
> Cheers,
> Steven Harris
>
> Director of Engineering
> [hidden email] <mailto:[hidden email]>
>
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

Alexander Voskoboynik
Jan,

I'll try to give short answers to your questions:

1. Terracotta session does not actually do anything when a context is being taken out of service.  We don't want to invalidate and/or  remove sessions just because one of the nodes in a cluster was shut down.  One of the reasons to use TC is to make those sessions available to other nodes that are still running.

2. We tried to make session scavenging efficient by
a) only one node in a cluster is allowed to run the scavenging thread at any point in time
b) we maintain a light-weight shared data structure (map of sessionId to estimated_expire_time) that allows the scavenger thread to fault in only those sessions that it can actually invalidate and remove.  The scavenger is implemented in TerracottaSessionManager.SessionInvalidator class (http://svn.terracotta.org/fisheye/browse/~raw,r=1729/Terracotta/dso/trunk/code/base/dso-l1-session/src/com/terracotta/session/TerracottaSessionManager.java)

In general, TC is integrated into a container as a Filter (or Valve in Tomcat's case) which intercepts all session-related calls.  I don't know if the same approach works for Jetty, but it might be worth looking into.  Another way to simplify your work might be to use TerracottaSessionManager inside of your SessionManager subclass.

Please let me know if you'd like more detailed info or have any other questions.

Alexander Voskoboynik
-- 
This e-mail incorporates Terracotta's confidentiality policy, which is online at http://www.terracottatech.com/emailconfidentiality.shtml





Jan Bartel wrote:
Hi Steven,

When you write it up, don't forget to post a link and I'll put it in the
Jetty wiki ;-)

Regarding sessions, because we're more familiar with Jetty code, we thought 
as our first cut at the Terracotta session integration, we thought we'd 
subclass our own SessionIdManager and SessionManager classes. That would 
entail overcoming these 2 edge cases in the current code to accommodate 
session replication:

  1. when a context is being taken out of service, the session map 
     is cleared out.

  2. session scavenging (as described below).

How does the terracotta session stuff handle 1 and 2? In particular, how
do you handle session scavenging? For example, in the current Jetty code
we set a timer and iterate over the list of sessions to find ones that 
have expired. In a clustered situation, that would cause all sessions 
to be shared across all nodes, which is clearly not desirable :-) 
How does TC handle that?

Also does terracotta sessions code handle session ids across cross-context 
dispatches?

cheers
Jan




Steven Harris wrote:
  
I took the latest version of jetty and added a root to a servlet and it
just worked. So for those 
who are interested in clustering outside of session you should be good
to go. I'll try to do a write up on the
steps when I get a free second.


Cheers,
Steven Harris

Director of Engineering
[hidden email] [hidden email]




------------------------------------------------------------------------

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


------------------------------------------------------------------------

_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
    

_______________________________________________
tc-dev mailing list
[hidden email]
http://lists.terracotta.org/mailman/listinfo/tc-dev
  

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

jan_bartel
Jonas, Steven, Alexander and others,

I've committed my experimental terracotta/jetty session code.

It is in the jetty-contrib repository at:
https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta

To build, you need maven2 and jdk1.5. Just typing "mvn clean install"
should do it.

The general idea is that a jetty user can use terracotta to cluster
their sessions by using the TerracottaSessionManager and
TerracottaSessionIdManager instead of the default jetty implementations
of HashSessionManager and HashSessionIdManager respectively.

Here's the way a jetty user would set this up for a particular web context:

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/test</Set>
  ...

 <New id="tcidmgr" class="org.mortbay.terracotta.servlet.TerracottaSessionIdManager">
   <Arg><Property name="Server"/></Arg>
   <Set name="workerName">fred</Set>
 </New>
 <New id="tcmgr" class="org.mortbay.terracotta.servlet.TerracottaSessionManager">
   <Set name="idManager"><Ref id="tcidmgr"/></Set>
 </New>
  ...
</Configure>

The shared roots are now:

+ org.mortbay.terracotta.servlet.TerracottaSessionManager._sessions
  This is the map of session id to session objects

+ org.mortbay.terracotta.servlet.TerracottaSessionManager._sessionTimeouts
  A map of session ids to expiry times

+ org.mortbay.terracotta.servlet.TerracottaSessionIdManager._sessionIds
  The set of unique sessionids in use within the cluster (handles cross-context dispatches)

I'm having difficulty getting my terracotta config file set up correctly.
I keep getting the "Attempt to access a shared object outside the scope of a shared lock."
exception:  

        at com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransactionManagerImpl.java:266)
        at com.tc.object.tx.ClientTransactionManagerImpl.checkWriteAccess(ClientTransactionManagerImpl.java:276)
        at com.tc.object.bytecode.ManagerImpl.checkWriteAccess(ManagerImpl.java:609)
        at com.tc.object.bytecode.ManagerUtil.checkWriteAccess(ManagerUtil.java:157)
        at java.util.HashSet.add(Unknown Source)
        at org.mortbay.terracotta.servlet.TerracottaSessionIdManager.addSession(TerracottaSessionIdManager.java:53)

I thought I configured the roots and the locks correctly in the config file, but
obviously not.

As this email is going to the jetty-discuss list, I can't attach the files, so
I'll send a separate email with a tar of the project, the terracotta config file
and a jetty config file to make this work with the jetty standard test webapp.

If you could take a look at this for me, it will no doubt save me many hours.

thanks in advance.
Jan

Alexander Voskoboynik wrote:

> Jan,
>
> I'll try to give short answers to your questions:
>
> 1. Terracotta session does not actually do anything when a context is
> being taken out of service.  We don't want to invalidate and/or  remove
> sessions just because one of the nodes in a cluster was shut down.  One
> of the reasons to use TC is to make those sessions available to other
> nodes that are still running.
>
> 2. We tried to make session scavenging efficient by
> a) only one node in a cluster is allowed to run the scavenging thread at
> any point in time
> b) we maintain a light-weight shared data structure (map of sessionId to
> estimated_expire_time) that allows the scavenger thread to fault in only
> those sessions that it can actually invalidate and remove.  The
> scavenger is implemented in TerracottaSessionManager.SessionInvalidator
> class
> (http://svn.terracotta.org/fisheye/browse/~raw,r=1729/Terracotta/dso/trunk/code/base/dso-l1-session/src/com/terracotta/session/TerracottaSessionManager.java)
>
> In general, TC is integrated into a container as a Filter (or Valve in
> Tomcat's case) which intercepts all session-related calls.  I don't know
> if the same approach works for Jetty, but it might be worth looking
> into.  Another way to simplify your work might be to use
> TerracottaSessionManager inside of your SessionManager subclass.
>
> Please let me know if you'd like more detailed info or have any other
> questions.
>
> Alexander Voskoboynik
> --
> This e-mail incorporates Terracotta's confidentiality policy, which is
> online at http://www.terracottatech.com/emailconfidentiality.shtml
>
>
>
>
>
> Jan Bartel wrote:
>> Hi Steven,
>>
>> When you write it up, don't forget to post a link and I'll put it in the
>> Jetty wiki ;-)
>>
>> Regarding sessions, because we're more familiar with Jetty code, we thought
>> as our first cut at the Terracotta session integration, we thought we'd
>> subclass our own SessionIdManager and SessionManager classes. That would
>> entail overcoming these 2 edge cases in the current code to accommodate
>> session replication:
>>
>>   1. when a context is being taken out of service, the session map
>>      is cleared out.
>>
>>   2. session scavenging (as described below).
>>
>> How does the terracotta session stuff handle 1 and 2? In particular, how
>> do you handle session scavenging? For example, in the current Jetty code
>> we set a timer and iterate over the list of sessions to find ones that
>> have expired. In a clustered situation, that would cause all sessions
>> to be shared across all nodes, which is clearly not desirable :-)
>> How does TC handle that?
>>
>> Also does terracotta sessions code handle session ids across cross-context
>> dispatches?
>>
>> cheers
>> Jan
>>
>>
>>
>>
>> Steven Harris wrote:
>>  
>>> I took the latest version of jetty and added a root to a servlet and it
>>> just worked. So for those
>>> who are interested in clustering outside of session you should be good
>>> to go. I'll try to do a write up on the
>>> steps when I get a free second.
>>>
>>>
>>> Cheers,
>>> Steven Harris
>>>
>>> Director of Engineering
>>> [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> jetty-discuss mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>>    
>>
>> _______________________________________________
>> tc-dev mailing list
>> [hidden email]
>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>  
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

teck-terracotta
Hi Jan,

        I'm a complete maven newbie, so it took me a while to glue this
all together. Here's what I could find (in particular order)

- The <include>/<exclude> sections of the TC config file are processed
bottom up. The exclude for "org.mortbay..*" therefore takes precedence
over the include for "org.mortbay.terracotta..*"

- The parent class of TerracottaSessionManager$Session
(org.mortbay.jetty.servlet.AbstractSessionManager$Session) needs to be
<included>'d.

- The method expression for your <autolock> probably wasn't matching what
you wanted it to match. I'm pretty sure you want something like "*
org.mortbay.terracotta.servlet.*.*(..)". That expression will apply
autolocks to all methods in all classes that are directly in the
"org.mortbay.terracotta.servlet" package. Here is some more info on the
syntax:
       
http://www.terracotta.org/confluence/display/docs1/AspectWerkz+Pattern+Lan
guage

- If you don't want to, you don't have to implement
__tc_setClassLoaderName() on your loader(s) (opting to throw an
UnsupportedOperationException maybe instead). DSO doesn't currently use
that method directly; it is a convenience to have it on the interface if
you need a setter.

With some of the above things in place, I ran into a somewhat harder
problem. I placed the terracotta-sessions-6.1-SNAPSHOT.jar directly in
jetty's lib directory, which I believe means it will be processed by your
top level loader (org.mortbay.start.Classpath$Loader). That loader does
not have the terracotta NamedClassLoader interface on it.

hope this helps. Please feel free to fire back with some follow up
questions
-tim

> -----Original Message-----
> From: [hidden email] [mailto:tc-dev-
> [hidden email]] On Behalf Of Jan Bartel
> Sent: Sunday, April 01, 2007 8:58 PM
> To: Discussion for Jetty development.; Discussion for Jetty
development.;

> [hidden email]
> Cc: [hidden email]
> Subject: Re: [tc-dev] Heads up on jetty/terracotta
>
> Jonas, Steven, Alexander and others,
>
> I've committed my experimental terracotta/jetty session code.
>
> It is in the jetty-contrib repository at:
> https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
>
> To build, you need maven2 and jdk1.5. Just typing "mvn clean install"
> should do it.
>
> The general idea is that a jetty user can use terracotta to cluster
> their sessions by using the TerracottaSessionManager and
> TerracottaSessionIdManager instead of the default jetty implementations
> of HashSessionManager and HashSessionIdManager respectively.
>
> Here's the way a jetty user would set this up for a particular web
> context:
>
> <Configure class="org.mortbay.jetty.webapp.WebAppContext">
>   <Set name="contextPath">/test</Set>
>   ...
>
>  <New id="tcidmgr"
> class="org.mortbay.terracotta.servlet.TerracottaSessionIdManager">
>    <Arg><Property name="Server"/></Arg>
>    <Set name="workerName">fred</Set>
>  </New>
>  <New id="tcmgr"
> class="org.mortbay.terracotta.servlet.TerracottaSessionManager">
>    <Set name="idManager"><Ref id="tcidmgr"/></Set>
>  </New>
>   ...
> </Configure>
>
> The shared roots are now:
>
> + org.mortbay.terracotta.servlet.TerracottaSessionManager._sessions
>   This is the map of session id to session objects
>
> +
org.mortbay.terracotta.servlet.TerracottaSessionManager._sessionTimeouts
>   A map of session ids to expiry times
>
> + org.mortbay.terracotta.servlet.TerracottaSessionIdManager._sessionIds
>   The set of unique sessionids in use within the cluster (handles cross-
> context dispatches)
>
> I'm having difficulty getting my terracotta config file set up
correctly.
> I keep getting the "Attempt to access a shared object outside the scope
of
> a shared lock."
> exception:
>
> at
>
com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransac
> tionManagerImpl.java:266)
> at
>
com.tc.object.tx.ClientTransactionManagerImpl.checkWriteAccess(ClientTrans
> actionManagerImpl.java:276)
> at
>
com.tc.object.bytecode.ManagerImpl.checkWriteAccess(ManagerImpl.java:609)
> at
>
com.tc.object.bytecode.ManagerUtil.checkWriteAccess(ManagerUtil.java:157)
> at java.util.HashSet.add(Unknown Source)
> at
>
org.mortbay.terracotta.servlet.TerracottaSessionIdManager.addSession(Terra

> cottaSessionIdManager.java:53)
>
> I thought I configured the roots and the locks correctly in the config
> file, but
> obviously not.
>
> As this email is going to the jetty-discuss list, I can't attach the
> files, so
> I'll send a separate email with a tar of the project, the terracotta
> config file
> and a jetty config file to make this work with the jetty standard test
> webapp.
>
> If you could take a look at this for me, it will no doubt save me many
> hours.
>
> thanks in advance.
> Jan
>
> Alexander Voskoboynik wrote:
> > Jan,
> >
> > I'll try to give short answers to your questions:
> >
> > 1. Terracotta session does not actually do anything when a context is
> > being taken out of service.  We don't want to invalidate and/or
remove
> > sessions just because one of the nodes in a cluster was shut down.
One
> > of the reasons to use TC is to make those sessions available to other
> > nodes that are still running.
> >
> > 2. We tried to make session scavenging efficient by
> > a) only one node in a cluster is allowed to run the scavenging thread
at
> > any point in time
> > b) we maintain a light-weight shared data structure (map of sessionId
to
> > estimated_expire_time) that allows the scavenger thread to fault in
only
> > those sessions that it can actually invalidate and remove.  The
> > scavenger is implemented in
TerracottaSessionManager.SessionInvalidator
> > class
> >
>
(http://svn.terracotta.org/fisheye/browse/~raw,r=1729/Terracotta/dso/trunk
> /code/base/dso-l1-
> session/src/com/terracotta/session/TerracottaSessionManager.java)
> >
> > In general, TC is integrated into a container as a Filter (or Valve in
> > Tomcat's case) which intercepts all session-related calls.  I don't
know

> > if the same approach works for Jetty, but it might be worth looking
> > into.  Another way to simplify your work might be to use
> > TerracottaSessionManager inside of your SessionManager subclass.
> >
> > Please let me know if you'd like more detailed info or have any other
> > questions.
> >
> > Alexander Voskoboynik
> > --
> > This e-mail incorporates Terracotta's confidentiality policy, which is
> > online at http://www.terracottatech.com/emailconfidentiality.shtml
> >
> >
> >
> >
> >
> > Jan Bartel wrote:
> >> Hi Steven,
> >>
> >> When you write it up, don't forget to post a link and I'll put it in
> the
> >> Jetty wiki ;-)
> >>
> >> Regarding sessions, because we're more familiar with Jetty code, we
> thought
> >> as our first cut at the Terracotta session integration, we thought
we'd
> >> subclass our own SessionIdManager and SessionManager classes. That
> would
> >> entail overcoming these 2 edge cases in the current code to
accommodate

> >> session replication:
> >>
> >>   1. when a context is being taken out of service, the session map
> >>      is cleared out.
> >>
> >>   2. session scavenging (as described below).
> >>
> >> How does the terracotta session stuff handle 1 and 2? In particular,
> how
> >> do you handle session scavenging? For example, in the current Jetty
> code
> >> we set a timer and iterate over the list of sessions to find ones
that

> >> have expired. In a clustered situation, that would cause all sessions
> >> to be shared across all nodes, which is clearly not desirable :-)
> >> How does TC handle that?
> >>
> >> Also does terracotta sessions code handle session ids across cross-
> context
> >> dispatches?
> >>
> >> cheers
> >> Jan
> >>
> >>
> >>
> >>
> >> Steven Harris wrote:
> >>
> >>> I took the latest version of jetty and added a root to a servlet and
> it
> >>> just worked. So for those
> >>> who are interested in clustering outside of session you should be
good

> >>> to go. I'll try to do a write up on the
> >>> steps when I get a free second.
> >>>
> >>>
> >>> Cheers,
> >>> Steven Harris
> >>>
> >>> Director of Engineering
> >>> [hidden email] <mailto:[hidden email]>
> >>>
> >>>
> >>>
> >>>
> >>>
----------------------------------------------------------------------
> --
> >>>
> >>>
----------------------------------------------------------------------
> ---
> >>> Take Surveys. Earn Cash. Influence the Future of IT
> >>> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> >>> opinions on IT & business topics through brief surveys-and earn cash
> >>>
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>
> >>>
> >>>
----------------------------------------------------------------------

> --
> >>>
> >>> _______________________________________________
> >>> jetty-discuss mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
> >>>
> >>
> >> _______________________________________________
> >> tc-dev mailing list
> >> [hidden email]
> >> http://lists.terracotta.org/mailman/listinfo/tc-dev
> >>
> >
> >
------------------------------------------------------------------------
> >
> >
------------------------------------------------------------------------
> -
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
share
> your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> >
> >
------------------------------------------------------------------------

> >
> > _______________________________________________
> > jetty-discuss mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
> _______________________________________________
> tc-dev mailing list
> [hidden email]
> http://lists.terracotta.org/mailman/listinfo/tc-dev


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

jan_bartel
Hi Tim,

Thanks for those tips! We're now both at the same stage. So I take it
that any classloader that interacts with Terracotta must implement
the NamedClassloader interface? Is there any magic you can put in the
terracotta startup to automatically include all of the likely
jetty classloaders?

cheers
Jan

Tim Eck wrote:

> Hi Jan,
>
> I'm a complete maven newbie, so it took me a while to glue this
> all together. Here's what I could find (in particular order)
>
> - The <include>/<exclude> sections of the TC config file are processed
> bottom up. The exclude for "org.mortbay..*" therefore takes precedence
> over the include for "org.mortbay.terracotta..*"
>
> - The parent class of TerracottaSessionManager$Session
> (org.mortbay.jetty.servlet.AbstractSessionManager$Session) needs to be
> <included>'d.
>
> - The method expression for your <autolock> probably wasn't matching what
> you wanted it to match. I'm pretty sure you want something like "*
> org.mortbay.terracotta.servlet.*.*(..)". That expression will apply
> autolocks to all methods in all classes that are directly in the
> "org.mortbay.terracotta.servlet" package. Here is some more info on the
> syntax:
>
> http://www.terracotta.org/confluence/display/docs1/AspectWerkz+Pattern+Lan
> guage
>
> - If you don't want to, you don't have to implement
> __tc_setClassLoaderName() on your loader(s) (opting to throw an
> UnsupportedOperationException maybe instead). DSO doesn't currently use
> that method directly; it is a convenience to have it on the interface if
> you need a setter.
>
> With some of the above things in place, I ran into a somewhat harder
> problem. I placed the terracotta-sessions-6.1-SNAPSHOT.jar directly in
> jetty's lib directory, which I believe means it will be processed by your
> top level loader (org.mortbay.start.Classpath$Loader). That loader does
> not have the terracotta NamedClassLoader interface on it.
>
> hope this helps. Please feel free to fire back with some follow up
> questions
> -tim
>
>> -----Original Message-----
>> From: [hidden email] [mailto:tc-dev-
>> [hidden email]] On Behalf Of Jan Bartel
>> Sent: Sunday, April 01, 2007 8:58 PM
>> To: Discussion for Jetty development.; Discussion for Jetty
> development.;
>> [hidden email]
>> Cc: [hidden email]
>> Subject: Re: [tc-dev] Heads up on jetty/terracotta
>>
>> Jonas, Steven, Alexander and others,
>>
>> I've committed my experimental terracotta/jetty session code.
>>
>> It is in the jetty-contrib repository at:
>> https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
>>
>> To build, you need maven2 and jdk1.5. Just typing "mvn clean install"
>> should do it.
>>
>> The general idea is that a jetty user can use terracotta to cluster
>> their sessions by using the TerracottaSessionManager and
>> TerracottaSessionIdManager instead of the default jetty implementations
>> of HashSessionManager and HashSessionIdManager respectively.
>>
>> Here's the way a jetty user would set this up for a particular web
>> context:
>>
>> <Configure class="org.mortbay.jetty.webapp.WebAppContext">
>>   <Set name="contextPath">/test</Set>
>>   ...
>>
>>  <New id="tcidmgr"
>> class="org.mortbay.terracotta.servlet.TerracottaSessionIdManager">
>>    <Arg><Property name="Server"/></Arg>
>>    <Set name="workerName">fred</Set>
>>  </New>
>>  <New id="tcmgr"
>> class="org.mortbay.terracotta.servlet.TerracottaSessionManager">
>>    <Set name="idManager"><Ref id="tcidmgr"/></Set>
>>  </New>
>>   ...
>> </Configure>
>>
>> The shared roots are now:
>>
>> + org.mortbay.terracotta.servlet.TerracottaSessionManager._sessions
>>   This is the map of session id to session objects
>>
>> +
> org.mortbay.terracotta.servlet.TerracottaSessionManager._sessionTimeouts
>>   A map of session ids to expiry times
>>
>> + org.mortbay.terracotta.servlet.TerracottaSessionIdManager._sessionIds
>>   The set of unique sessionids in use within the cluster (handles cross-
>> context dispatches)
>>
>> I'm having difficulty getting my terracotta config file set up
> correctly.
>> I keep getting the "Attempt to access a shared object outside the scope
> of
>> a shared lock."
>> exception:
>>
>> at
>>
> com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransac
>> tionManagerImpl.java:266)
>> at
>>
> com.tc.object.tx.ClientTransactionManagerImpl.checkWriteAccess(ClientTrans
>> actionManagerImpl.java:276)
>> at
>>
> com.tc.object.bytecode.ManagerImpl.checkWriteAccess(ManagerImpl.java:609)
>> at
>>
> com.tc.object.bytecode.ManagerUtil.checkWriteAccess(ManagerUtil.java:157)
>> at java.util.HashSet.add(Unknown Source)
>> at
>>
> org.mortbay.terracotta.servlet.TerracottaSessionIdManager.addSession(Terra
>> cottaSessionIdManager.java:53)
>>
>> I thought I configured the roots and the locks correctly in the config
>> file, but
>> obviously not.
>>
>> As this email is going to the jetty-discuss list, I can't attach the
>> files, so
>> I'll send a separate email with a tar of the project, the terracotta
>> config file
>> and a jetty config file to make this work with the jetty standard test
>> webapp.
>>
>> If you could take a look at this for me, it will no doubt save me many
>> hours.
>>
>> thanks in advance.
>> Jan
>>
>> Alexander Voskoboynik wrote:
>>> Jan,
>>>
>>> I'll try to give short answers to your questions:
>>>
>>> 1. Terracotta session does not actually do anything when a context is
>>> being taken out of service.  We don't want to invalidate and/or
> remove
>>> sessions just because one of the nodes in a cluster was shut down.
> One
>>> of the reasons to use TC is to make those sessions available to other
>>> nodes that are still running.
>>>
>>> 2. We tried to make session scavenging efficient by
>>> a) only one node in a cluster is allowed to run the scavenging thread
> at
>>> any point in time
>>> b) we maintain a light-weight shared data structure (map of sessionId
> to
>>> estimated_expire_time) that allows the scavenger thread to fault in
> only
>>> those sessions that it can actually invalidate and remove.  The
>>> scavenger is implemented in
> TerracottaSessionManager.SessionInvalidator
>>> class
>>>
> (http://svn.terracotta.org/fisheye/browse/~raw,r=1729/Terracotta/dso/trunk
>> /code/base/dso-l1-
>> session/src/com/terracotta/session/TerracottaSessionManager.java)
>>> In general, TC is integrated into a container as a Filter (or Valve in
>>> Tomcat's case) which intercepts all session-related calls.  I don't
> know
>>> if the same approach works for Jetty, but it might be worth looking
>>> into.  Another way to simplify your work might be to use
>>> TerracottaSessionManager inside of your SessionManager subclass.
>>>
>>> Please let me know if you'd like more detailed info or have any other
>>> questions.
>>>
>>> Alexander Voskoboynik
>>> --
>>> This e-mail incorporates Terracotta's confidentiality policy, which is
>>> online at http://www.terracottatech.com/emailconfidentiality.shtml
>>>
>>>
>>>
>>>
>>>
>>> Jan Bartel wrote:
>>>> Hi Steven,
>>>>
>>>> When you write it up, don't forget to post a link and I'll put it in
>> the
>>>> Jetty wiki ;-)
>>>>
>>>> Regarding sessions, because we're more familiar with Jetty code, we
>> thought
>>>> as our first cut at the Terracotta session integration, we thought
> we'd
>>>> subclass our own SessionIdManager and SessionManager classes. That
>> would
>>>> entail overcoming these 2 edge cases in the current code to
> accommodate
>>>> session replication:
>>>>
>>>>   1. when a context is being taken out of service, the session map
>>>>      is cleared out.
>>>>
>>>>   2. session scavenging (as described below).
>>>>
>>>> How does the terracotta session stuff handle 1 and 2? In particular,
>> how
>>>> do you handle session scavenging? For example, in the current Jetty
>> code
>>>> we set a timer and iterate over the list of sessions to find ones
> that
>>>> have expired. In a clustered situation, that would cause all sessions
>>>> to be shared across all nodes, which is clearly not desirable :-)
>>>> How does TC handle that?
>>>>
>>>> Also does terracotta sessions code handle session ids across cross-
>> context
>>>> dispatches?
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>>
>>>>
>>>>
>>>> Steven Harris wrote:
>>>>
>>>>> I took the latest version of jetty and added a root to a servlet and
>> it
>>>>> just worked. So for those
>>>>> who are interested in clustering outside of session you should be
> good
>>>>> to go. I'll try to do a write up on the
>>>>> steps when I get a free second.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Steven Harris
>>>>>
>>>>> Director of Engineering
>>>>> [hidden email] <mailto:[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ----------------------------------------------------------------------
>> --
>>>>>
> ----------------------------------------------------------------------
>> ---
>>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>>>>> opinions on IT & business topics through brief surveys-and earn cash
>>>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>>>
>>>>>
> ----------------------------------------------------------------------
>> --
>>>>> _______________________________________________
>>>>> jetty-discuss mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>>>>
>>>> _______________________________________________
>>>> tc-dev mailing list
>>>> [hidden email]
>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>>>
>>>
> ------------------------------------------------------------------------
>>>
> ------------------------------------------------------------------------
>> -
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
> share
>> your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>
>>>
> ------------------------------------------------------------------------
>>> _______________________________________________
>>> jetty-discuss mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>> _______________________________________________
>> tc-dev mailing list
>> [hidden email]
>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

jan_bartel
In reply to this post by teck-terracotta
Sorry if this is received twice, but thunderbird crashed on me when I
hit "send" ...


Thanks for these tips Tim! We're now both at the same stage. So I take
it that all classloaders that interact with terracotta should implement
the NamedClassLoader interface? Alternatively, is there any magic you
could put in the terracotta startup that would automatically include
all of the jetty classloaders without us having to implement that
interface?

cheers
Jan


Tim Eck wrote:

> Hi Jan,
>
> I'm a complete maven newbie, so it took me a while to glue this
> all together. Here's what I could find (in particular order)
>
> - The <include>/<exclude> sections of the TC config file are processed
> bottom up. The exclude for "org.mortbay..*" therefore takes precedence
> over the include for "org.mortbay.terracotta..*"
>
> - The parent class of TerracottaSessionManager$Session
> (org.mortbay.jetty.servlet.AbstractSessionManager$Session) needs to be
> <included>'d.
>
> - The method expression for your <autolock> probably wasn't matching what
> you wanted it to match. I'm pretty sure you want something like "*
> org.mortbay.terracotta.servlet.*.*(..)". That expression will apply
> autolocks to all methods in all classes that are directly in the
> "org.mortbay.terracotta.servlet" package. Here is some more info on the
> syntax:
>
> http://www.terracotta.org/confluence/display/docs1/AspectWerkz+Pattern+Lan
> guage
>
> - If you don't want to, you don't have to implement
> __tc_setClassLoaderName() on your loader(s) (opting to throw an
> UnsupportedOperationException maybe instead). DSO doesn't currently use
> that method directly; it is a convenience to have it on the interface if
> you need a setter.
>
> With some of the above things in place, I ran into a somewhat harder
> problem. I placed the terracotta-sessions-6.1-SNAPSHOT.jar directly in
> jetty's lib directory, which I believe means it will be processed by your
> top level loader (org.mortbay.start.Classpath$Loader). That loader does
> not have the terracotta NamedClassLoader interface on it.
>
> hope this helps. Please feel free to fire back with some follow up
> questions
> -tim
>
>> -----Original Message-----
>> From: [hidden email] [mailto:tc-dev-
>> [hidden email]] On Behalf Of Jan Bartel
>> Sent: Sunday, April 01, 2007 8:58 PM
>> To: Discussion for Jetty development.; Discussion for Jetty
> development.;
>> [hidden email]
>> Cc: [hidden email]
>> Subject: Re: [tc-dev] Heads up on jetty/terracotta
>>
>> Jonas, Steven, Alexander and others,
>>
>> I've committed my experimental terracotta/jetty session code.
>>
>> It is in the jetty-contrib repository at:
>> https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
>>
>> To build, you need maven2 and jdk1.5. Just typing "mvn clean install"
>> should do it.
>>
>> The general idea is that a jetty user can use terracotta to cluster
>> their sessions by using the TerracottaSessionManager and
>> TerracottaSessionIdManager instead of the default jetty implementations
>> of HashSessionManager and HashSessionIdManager respectively.
>>
>> Here's the way a jetty user would set this up for a particular web
>> context:
>>
>> <Configure class="org.mortbay.jetty.webapp.WebAppContext">
>>   <Set name="contextPath">/test</Set>
>>   ...
>>
>>  <New id="tcidmgr"
>> class="org.mortbay.terracotta.servlet.TerracottaSessionIdManager">
>>    <Arg><Property name="Server"/></Arg>
>>    <Set name="workerName">fred</Set>
>>  </New>
>>  <New id="tcmgr"
>> class="org.mortbay.terracotta.servlet.TerracottaSessionManager">
>>    <Set name="idManager"><Ref id="tcidmgr"/></Set>
>>  </New>
>>   ...
>> </Configure>
>>
>> The shared roots are now:
>>
>> + org.mortbay.terracotta.servlet.TerracottaSessionManager._sessions
>>   This is the map of session id to session objects
>>
>> +
> org.mortbay.terracotta.servlet.TerracottaSessionManager._sessionTimeouts
>>   A map of session ids to expiry times
>>
>> + org.mortbay.terracotta.servlet.TerracottaSessionIdManager._sessionIds
>>   The set of unique sessionids in use within the cluster (handles cross-
>> context dispatches)
>>
>> I'm having difficulty getting my terracotta config file set up
> correctly.
>> I keep getting the "Attempt to access a shared object outside the scope
> of
>> a shared lock."
>> exception:
>>
>> at
>>
> com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransac
>> tionManagerImpl.java:266)
>> at
>>
> com.tc.object.tx.ClientTransactionManagerImpl.checkWriteAccess(ClientTrans
>> actionManagerImpl.java:276)
>> at
>>
> com.tc.object.bytecode.ManagerImpl.checkWriteAccess(ManagerImpl.java:609)
>> at
>>
> com.tc.object.bytecode.ManagerUtil.checkWriteAccess(ManagerUtil.java:157)
>> at java.util.HashSet.add(Unknown Source)
>> at
>>
> org.mortbay.terracotta.servlet.TerracottaSessionIdManager.addSession(Terra
>> cottaSessionIdManager.java:53)
>>
>> I thought I configured the roots and the locks correctly in the config
>> file, but
>> obviously not.
>>
>> As this email is going to the jetty-discuss list, I can't attach the
>> files, so
>> I'll send a separate email with a tar of the project, the terracotta
>> config file
>> and a jetty config file to make this work with the jetty standard test
>> webapp.
>>
>> If you could take a look at this for me, it will no doubt save me many
>> hours.
>>
>> thanks in advance.
>> Jan
>>
>> Alexander Voskoboynik wrote:
>>> Jan,
>>>
>>> I'll try to give short answers to your questions:
>>>
>>> 1. Terracotta session does not actually do anything when a context is
>>> being taken out of service.  We don't want to invalidate and/or
> remove
>>> sessions just because one of the nodes in a cluster was shut down.
> One
>>> of the reasons to use TC is to make those sessions available to other
>>> nodes that are still running.
>>>
>>> 2. We tried to make session scavenging efficient by
>>> a) only one node in a cluster is allowed to run the scavenging thread
> at
>>> any point in time
>>> b) we maintain a light-weight shared data structure (map of sessionId
> to
>>> estimated_expire_time) that allows the scavenger thread to fault in
> only
>>> those sessions that it can actually invalidate and remove.  The
>>> scavenger is implemented in
> TerracottaSessionManager.SessionInvalidator
>>> class
>>>
> (http://svn.terracotta.org/fisheye/browse/~raw,r=1729/Terracotta/dso/trunk
>> /code/base/dso-l1-
>> session/src/com/terracotta/session/TerracottaSessionManager.java)
>>> In general, TC is integrated into a container as a Filter (or Valve in
>>> Tomcat's case) which intercepts all session-related calls.  I don't
> know
>>> if the same approach works for Jetty, but it might be worth looking
>>> into.  Another way to simplify your work might be to use
>>> TerracottaSessionManager inside of your SessionManager subclass.
>>>
>>> Please let me know if you'd like more detailed info or have any other
>>> questions.
>>>
>>> Alexander Voskoboynik
>>> --
>>> This e-mail incorporates Terracotta's confidentiality policy, which is
>>> online at http://www.terracottatech.com/emailconfidentiality.shtml
>>>
>>>
>>>
>>>
>>>
>>> Jan Bartel wrote:
>>>> Hi Steven,
>>>>
>>>> When you write it up, don't forget to post a link and I'll put it in
>> the
>>>> Jetty wiki ;-)
>>>>
>>>> Regarding sessions, because we're more familiar with Jetty code, we
>> thought
>>>> as our first cut at the Terracotta session integration, we thought
> we'd
>>>> subclass our own SessionIdManager and SessionManager classes. That
>> would
>>>> entail overcoming these 2 edge cases in the current code to
> accommodate
>>>> session replication:
>>>>
>>>>   1. when a context is being taken out of service, the session map
>>>>      is cleared out.
>>>>
>>>>   2. session scavenging (as described below).
>>>>
>>>> How does the terracotta session stuff handle 1 and 2? In particular,
>> how
>>>> do you handle session scavenging? For example, in the current Jetty
>> code
>>>> we set a timer and iterate over the list of sessions to find ones
> that
>>>> have expired. In a clustered situation, that would cause all sessions
>>>> to be shared across all nodes, which is clearly not desirable :-)
>>>> How does TC handle that?
>>>>
>>>> Also does terracotta sessions code handle session ids across cross-
>> context
>>>> dispatches?
>>>>
>>>> cheers
>>>> Jan
>>>>
>>>>
>>>>
>>>>
>>>> Steven Harris wrote:
>>>>
>>>>> I took the latest version of jetty and added a root to a servlet and
>> it
>>>>> just worked. So for those
>>>>> who are interested in clustering outside of session you should be
> good
>>>>> to go. I'll try to do a write up on the
>>>>> steps when I get a free second.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Steven Harris
>>>>>
>>>>> Director of Engineering
>>>>> [hidden email] <mailto:[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ----------------------------------------------------------------------
>> --
>>>>>
> ----------------------------------------------------------------------
>> ---
>>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>>>>> opinions on IT & business topics through brief surveys-and earn cash
>>>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>>>
>>>>>
> ----------------------------------------------------------------------
>> --
>>>>> _______________________________________________
>>>>> jetty-discuss mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>>>>>
>>>> _______________________________________________
>>>> tc-dev mailing list
>>>> [hidden email]
>>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>>>
>>>
> ------------------------------------------------------------------------
>>>
> ------------------------------------------------------------------------
>> -
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
> share
>> your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>
>>>
> ------------------------------------------------------------------------
>>> _______________________________________________
>>> jetty-discuss mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>> _______________________________________________
>> tc-dev mailing list
>> [hidden email]
>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

teck-terracotta
In reply to this post by jan_bartel
> So I take it
> that any classloader that interacts with Terracotta must implement
> the NamedClassloader interface?

Yes, anytime an object is becomes shared/distributed we need to record the
identity of the loader which defined the class of the instance.

> Is there any magic you can put in the
> terracotta startup to automatically include all of the likely
> jetty classloaders?

It probably wouldn't take too much work to add some load time
instrumentation to introduce the NamedClassLoader interface to the jetty
loaders. It seems as though they already have the concept of "name", so it
might be as simple as just delegating the interface methods to existing
ones. If I were adding Jetty support to our product, that would be one of
the very first things I would do :-)

-tim



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

sharrissf
Could this be done with aspectwerkz or aspect j from within a config module?


Cheers,
Steven Harris

Director of Engineering



On Apr 3, 2007, at 12:20 PM, Tim Eck wrote:

So I take it
that any classloader that interacts with Terracotta must implement
the NamedClassloader interface?

Yes, anytime an object is becomes shared/distributed we need to record the
identity of the loader which defined the class of the instance.

Is there any magic you can put in the
terracotta startup to automatically include all of the likely
jetty classloaders?

It probably wouldn't take too much work to add some load time
instrumentation to introduce the NamedClassLoader interface to the jetty
loaders. It seems as though they already have the concept of "name", so it
might be as simple as just delegating the interface methods to existing
ones. If I were adding Jetty support to our product, that would be one of
the very first things I would do :-)

-tim


_______________________________________________
tc-dev mailing list


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

teck-terracotta

I’m certain a config module can provide class adapters, and more than likely you can arrange for an AW aspect to be registered. It might take a little doing to use aspectJ from within a DSO config module, but I say that mostly because I have no idea what would be involved J

 


From: Steven Harris [mailto:[hidden email]]
Sent: Tuesday, April 03, 2007 12:33 PM
To: Tim Eck
Cc: Jan Bartel; [hidden email]; Discussion for Jetty development.
Subject: Re: [tc-dev] Heads up on jetty/terracotta

 

Could this be done with aspectwerkz or aspect j from within a config module?

 

On Apr 3, 2007, at 12:20 PM, Tim Eck wrote:



So I take it

that any classloader that interacts with Terracotta must implement

the NamedClassloader interface?

 

Yes, anytime an object is becomes shared/distributed we need to record the

identity of the loader which defined the class of the instance.

 

Is there any magic you can put in the

terracotta startup to automatically include all of the likely

jetty classloaders?

 

It probably wouldn't take too much work to add some load time

instrumentation to introduce the NamedClassLoader interface to the jetty

loaders. It seems as though they already have the concept of "name", so it

might be as simple as just delegating the interface methods to existing

ones. If I were adding Jetty support to our product, that would be one of

the very first things I would do :-)

 

-tim


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

sharrissf
Yeah, aspectwerkz is already integrated because we use it for spring so it might be easier.


Cheers,
Steven Harris

Director of Engineering



On Apr 3, 2007, at 12:44 PM, Tim Eck wrote:

I’m certain a config module can provide class adapters, and more than likely you can arrange for an AW aspect to be registered. It might take a little doing to use aspectJ from within a DSO config module, but I say that mostly because I have no idea what would be involved J

 


From: Steven Harris [[hidden email]]
Sent: Tuesday, April 03, 2007 12:33 PM
To: Tim Eck
Cc: Jan Bartel; [hidden email]; Discussion for Jetty development.
Subject: Re: [tc-dev] Heads up on jetty/terracotta

 

Could this be done with aspectwerkz or aspect j from within a config module?

 

On Apr 3, 2007, at 12:20 PM, Tim Eck wrote:



So I take it

that any classloader that interacts with Terracotta must implement

the NamedClassloader interface?

 

Yes, anytime an object is becomes shared/distributed we need to record the

identity of the loader which defined the class of the instance.

 

Is there any magic you can put in the

terracotta startup to automatically include all of the likely

jetty classloaders?

 

It probably wouldn't take too much work to add some load time

instrumentation to introduce the NamedClassLoader interface to the jetty

loaders. It seems as though they already have the concept of "name", so it

might be as simple as just delegating the interface methods to existing

ones. If I were adding Jetty support to our product, that would be one of

the very first things I would do :-)

 

-tim




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

jan_bartel
In reply to this post by teck-terracotta
Tim Eck wrote:

>> Is there any magic you can put in the
>> terracotta startup to automatically include all of the likely
>> jetty classloaders?
>
> It probably wouldn't take too much work to add some load time
> instrumentation to introduce the NamedClassLoader interface to the jetty
> loaders. It seems as though they already have the concept of "name", so it
> might be as simple as just delegating the interface methods to existing
> ones. If I were adding Jetty support to our product, that would be one of
> the very first things I would do :-)

Errr, I'm confused now. I thought that's what we *were* doing????

I'm kinda overcommitted by about 900% right now, so I'm going to need to
de-prioritize this for a while. In any case, it seems like
some support in terracotta is required to really move forward, so
I'll wait to hear from you guys before I try and snatch some more
time to work on this.


cheers
Jan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

Jonas Bonér-2
In reply to this post by sharrissf
This was discussed some time ago:

http://www.nabble.com/classloader-identity-tf3118839.html#a8640571
http://www.nabble.com/ClassLoader-identity-problem-tf3118777.html#a8640352

This discusses how to do it in AspectJ, the simplest way of hooking that
into TC is to package it in a jar and use the AJ javaagent (or simly
precompile the classes).

But doing it in AW would be just as simple, and already integrated in
TC. I can provide pointers to where to hook an AW aspect into the TC
core, if someone is interested.

I think that someone should look at building the AW/TC config module
glue. Would be very useful to get away with a 5 line aspect rather than
having to do an ASM adaptor every single time.

Steven Harris wrote:

> Yeah, aspectwerkz is already integrated because we use it for spring so
> it might be easier.
>
>
> Cheers,
> Steven Harris
>
> Director of Engineering
> [hidden email] <mailto:[hidden email]>
>
>
>
> On Apr 3, 2007, at 12:44 PM, Tim Eck wrote:
>
>> I’m certain a config module can provide class adapters, and more than
>> likely you can arrange for an AW aspect to be registered. It might
>> take a little doing to use aspectJ from within a DSO config module,
>> but I say that mostly because I have no idea what would be involved J
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Steven Harris [mailto:[hidden email]]
>> *Sent:* Tuesday, April 03, 2007 12:33 PM
>> *To:* Tim Eck
>> *Cc:* Jan Bartel; [hidden email]
>> <mailto:[hidden email]>; Discussion for Jetty development.
>> *Subject:* Re: [tc-dev] Heads up on jetty/terracotta
>>
>>  
>>
>> Could this be done with aspectwerkz or aspect j from within a config
>> module?
>>
>>  
>>
>> On Apr 3, 2007, at 12:20 PM, Tim Eck wrote:
>>
>>
>>
>>> So I take it
>>>
>>> that any classloader that interacts with Terracotta must implement
>>>
>>> the NamedClassloader interface?
>>>
>>  
>>
>> Yes, anytime an object is becomes shared/distributed we need to record the
>>
>> identity of the loader which defined the class of the instance.
>>
>>  
>>
>>> Is there any magic you can put in the
>>>
>>> terracotta startup to automatically include all of the likely
>>>
>>> jetty classloaders?
>>>
>>  
>>
>> It probably wouldn't take too much work to add some load time
>>
>> instrumentation to introduce the NamedClassLoader interface to the jetty
>>
>> loaders. It seems as though they already have the concept of "name", so it
>>
>> might be as simple as just delegating the interface methods to existing
>>
>> ones. If I were adding Jetty support to our product, that would be one of
>>
>> the very first things I would do :-)
>>
>>  
>>
>> -tim
>>
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> tc-dev mailing list
> [hidden email]
> http://lists.terracotta.org/mailman/listinfo/tc-dev

--
Jonas Bonér

http://jonasboner.com


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [tc-dev] Heads up on jetty/terracotta

sharrissf
We'll have to do something like what you said once we move Spring to be a true config module.

Cheers,
Steven Harris

Director of Engineering



On Apr 3, 2007, at 11:06 PM, Jonas Bonér wrote:

This was discussed some time ago:


This discusses how to do it in AspectJ, the simplest way of hooking that into TC is to package it in a jar and use the AJ javaagent (or simly precompile the classes).

But doing it in AW would be just as simple, and already integrated in TC. I can provide pointers to where to hook an AW aspect into the TC core, if someone is interested.

I think that someone should look at building the AW/TC config module glue. Would be very useful to get away with a 5 line aspect rather than having to do an ASM adaptor every single time.

Steven Harris wrote:
Yeah, aspectwerkz is already integrated because we use it for spring so it might be easier.
Cheers,
Steven Harris
Director of Engineering
On Apr 3, 2007, at 12:44 PM, Tim Eck wrote:
I’m certain a config module can provide class adapters, and more than likely you can arrange for an AW aspect to be registered. It might take a little doing to use aspectJ from within a DSO config module, but I say that mostly because I have no idea what would be involved J

 

------------------------------------------------------------------------

*From:* Steven Harris [[hidden email]]
*Sent:* Tuesday, April 03, 2007 12:33 PM
*To:* Tim Eck
*Cc:* Jan Bartel; [hidden email] <[hidden email]>; Discussion for Jetty development.
*Subject:* Re: [tc-dev] Heads up on jetty/terracotta

 

Could this be done with aspectwerkz or aspect j from within a config module?

 

On Apr 3, 2007, at 12:20 PM, Tim Eck wrote:



So I take it

that any classloader that interacts with Terracotta must implement

the NamedClassloader interface?

 

Yes, anytime an object is becomes shared/distributed we need to record the

identity of the loader which defined the class of the instance.

 

Is there any magic you can put in the

terracotta startup to automatically include all of the likely

jetty classloaders?

 

It probably wouldn't take too much work to add some load time

instrumentation to introduce the NamedClassLoader interface to the jetty

loaders. It seems as though they already have the concept of "name", so it

might be as simple as just delegating the interface methods to existing

ones. If I were adding Jetty support to our product, that would be one of

the very first things I would do :-)

 

-tim


------------------------------------------------------------------------
_______________________________________________
tc-dev mailing list

-- 
Jonas Bonér




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

jetty/terracotta

teck-terracotta
In reply to this post by jan_bartel
Hi All,

        I've committed some stuff to help move Jetty+Terracotta forward
(http://svn.terracotta.org/fisheye/changelog/Terracotta/?cs=2312)

There is now a "module" for Jetty 6.1 checked into terracotta trunk. Right
now all the module provides is the necessary NamedClassLoader stuff for
Jetty's loaders. To enable the module, tc-config.xml needs to include
something like this:

<tc:tc-config xmlns:tc="http://www.terracotta.org/config">
  ...
  <clients>
    ...
    <modules>
      <module name="clustered-jetty-6.1" version="1.0.0"/>
    </modules>
  </clients>
  ...
</tc:tc-config>

Some other notes:
- I believe the next challenge to solve with the TerracottSessionManager
is the fact that the Session class is a non-static inner. Non-static inner
classes work fine in Terracotta, but in this case it might be problematic
since they maintain a (compiler generated) reference back to the enclosing
class. This means that when Session instances are put in the distributed
map we follow the graph into the session manager (which itself should not
shared). If feasible, removing the parent reference would make this
problem go away. Another approach is make it a static inner and pass the
session manager in the constructor and storing it in a transient field

- I don't know if it is an issue, but the use of a single root for all
sessions might not provide the correct isolation for each context. It's
possible that the key generation accounts for this though (I didn't study
it too hard). The thing that is unexpected about roots is just how broad
their scope is. Some reading material on DSO roots:
http://www.terracotta.org/confluence/display/docs1/Concept+and+Architectur
e+Guide#ConceptandArchitectureGuide-Roots

- For the name of the WebAppClassLoader, I used the context path
associated with it rather then the display name. I could be wrong, but I'm
assuming that display name comes directly from WEB-INF/web.xml and is
really just an arbitrary descriptor (and optional too?).

- The support for org.mortbay.start.Classpath$Loader is not as clean as I
would prefer. I changed Classpath.getClassLoader() to do the loader naming
on the returned loader. That method is called more than once during
startup, so more than one instance ends up being named and registered with
DSO. It just happens that the last one created is the one that actually
starts the server. https://jira.terracotta.org/jira/browse/CDV-212 exists
to fix that



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: jetty/terracotta

jan_bartel
At long last I've been able to devote a bit of time to jetty/terracotta
integration.

Thanks Tim for those mods to the terracotta source to support jetty.
They're working a treat.

I've changed approach a little to overcome the problem you mentioned
with the AbstractSessionManager$Session class. I've created a new
class TerracottaSessionManager$SessionData which holds just the
information of the session. All the SessionData objects are put
into a clustered ConcurrentHashMap. The Session object now delegates
to it's corresponding SessionData object. Each TerracottaSessionManager
has a (non-clustered) map of Session objects and a clustered map of
SessionData objects. Session objects are put into the map when either
a) a session is created on that node.
b) a clustered session's presence is requested on that node

I hope that makes sense. Please ask me to explain better if it doesn't.

As we're about to do a Jetty release, I've had to branch the jetty code
to make some minor mods to the AbstractSessionManager$Session class
(simply just to change the scope of it's data members to "protected").


So the instructions for testing out jetty in terracotta are now as
follows:

1. Check out jetty from  https://svn.codehaus.org/jetty/jetty/branches/terracotta
2. Build it with "mvn clean install" at the top level

3. Check out the jetty-terracotta integration code as part of jetty-contrib
  at https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
4. Build it with "mvn clean install" at the top level
5. Copy the target/terracotta-sessions-6.1-SNAPSHOT.jar into the lib/ext
  directory of the jetty you built in step 1.

6. Build terracotta with the jetty module changes in it and make a bootjar

7. Use the tc-config.xml file from the jetty-contrib/extras/terracotta
   project to start the tc server

8. Copy the jetty-contrib/extras/terracotta/src/resources/terracotta-test.xml
   file into the contexts/ directory of the jetty server you built in step1.

9. Start a jetty instance with terracotta:

 java -Dtc.install-root=$TC_HOME \
 -Xbootclasspath/p:[location-of-boot-jar] \
 -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar


I've been testing this by turning off session cookies in my browser (forcing
the use of url rewriting) and using the test application's session dump
servlet to create servlets, add/remove attribute values. The servlet is
available at: http://localhost:8080/terracottatest/session (or just click
on the "Session Dump" link from the page at http://localhost:8080/terracottatest).

I've created a second Jetty instance running on the same machine at a different
port number. I've checked that in at jetty-contrib/extras/terracotta/src/resources/other-jetty.xml.
Use it by copying it to your etc/ directory in your jetty instance, then naming it on
the command line when starting the second instance:

 java -Dtc.install-root=$TC_HOME \
 -Xbootclasspath/p:[location-of-boot-jar] \
 -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar \
  etc/other-jetty.xml


So, you should be able to create a session at http://localhost:8080/terracottatest/session,
then cut and paste the url with the jsessionid you get back into a second window/tab of
your browser and change the port number to 8181 and see the same session.

I've tested that session attribute setting/removes and session invalidation is
reflected across both instances, but I have yet to test that session scavenging
works.

If you have a test bed where you could run up multiple jetty instances on multiple
machines (and use cookies for sessions) that would be a big help.

Any comments/suggestions on the code would be very welcome.

cheers
Jan



Tim Eck wrote:

> Hi All,
>
> I've committed some stuff to help move Jetty+Terracotta forward
> (http://svn.terracotta.org/fisheye/changelog/Terracotta/?cs=2312)
>
> There is now a "module" for Jetty 6.1 checked into terracotta trunk. Right
> now all the module provides is the necessary NamedClassLoader stuff for
> Jetty's loaders. To enable the module, tc-config.xml needs to include
> something like this:
>
> <tc:tc-config xmlns:tc="http://www.terracotta.org/config">
>   ...
>   <clients>
>     ...
>     <modules>
>       <module name="clustered-jetty-6.1" version="1.0.0"/>
>     </modules>
>   </clients>
>   ...
> </tc:tc-config>
>
> Some other notes:
> - I believe the next challenge to solve with the TerracottSessionManager
> is the fact that the Session class is a non-static inner. Non-static inner
> classes work fine in Terracotta, but in this case it might be problematic
> since they maintain a (compiler generated) reference back to the enclosing
> class. This means that when Session instances are put in the distributed
> map we follow the graph into the session manager (which itself should not
> shared). If feasible, removing the parent reference would make this
> problem go away. Another approach is make it a static inner and pass the
> session manager in the constructor and storing it in a transient field
>
> - I don't know if it is an issue, but the use of a single root for all
> sessions might not provide the correct isolation for each context. It's
> possible that the key generation accounts for this though (I didn't study
> it too hard). The thing that is unexpected about roots is just how broad
> their scope is. Some reading material on DSO roots:
> http://www.terracotta.org/confluence/display/docs1/Concept+and+Architectur
> e+Guide#ConceptandArchitectureGuide-Roots
>
> - For the name of the WebAppClassLoader, I used the context path
> associated with it rather then the display name. I could be wrong, but I'm
> assuming that display name comes directly from WEB-INF/web.xml and is
> really just an arbitrary descriptor (and optional too?).
>
> - The support for org.mortbay.start.Classpath$Loader is not as clean as I
> would prefer. I changed Classpath.getClassLoader() to do the loader naming
> on the returned loader. That method is called more than once during
> startup, so more than one instance ends up being named and registered with
> DSO. It just happens that the last one created is the one that actually
> starts the server. https://jira.terracotta.org/jira/browse/CDV-212 exists
> to fix that
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: jetty/terracotta

teck-terracotta
I loaded up the latest stuff and tried it out -- seems to be functional
(p.s. thanks for the detailed setup steps).

As far as testing is concerned, we have a framework of sorts for
validating distributed sessions. It takes care of spinning up 2+
Terracotta enabled web containers, a terracotta server and then executing
the test logic. Wherever possible, the framework uses cargo
(http://cargo.codehaus.org) to deal with the container specifics. From the
cargo docs though, it seems like only jetty is only supported for embedded
use? (we'd want the jetty instances to be standalone java procs). Not a
big deal, just something we'd have to cook up internally. A few of our
tests probably depend on details of our session implementation in some
way, but again we can deal with that.

I think most of the tc-config-jetty.xml can be moved into the jetty module
that is part of the terracotta distribution (includes, locks and roots). I
can go ahead and do that if there are no objections.

One tiny little thing I noticed in the code was on lines 133-134 of
TerracottaSessionIdManager -- It probably doesn't matter, but there is one
case where the value of "r" will stay negative: Long.MIN_VALUE;

> -----Original Message-----
> From: Jan Bartel [mailto:[hidden email]]
> Sent: Thursday, April 19, 2007 7:34 PM
> To: Discussion for Jetty development.
> Cc: [hidden email]; Tim Eck
> Subject: Re: jetty/terracotta
>
> At long last I've been able to devote a bit of time to jetty/terracotta
> integration.
>
> Thanks Tim for those mods to the terracotta source to support jetty.
> They're working a treat.
>
> I've changed approach a little to overcome the problem you mentioned
> with the AbstractSessionManager$Session class. I've created a new
> class TerracottaSessionManager$SessionData which holds just the
> information of the session. All the SessionData objects are put
> into a clustered ConcurrentHashMap. The Session object now delegates
> to it's corresponding SessionData object. Each TerracottaSessionManager
> has a (non-clustered) map of Session objects and a clustered map of
> SessionData objects. Session objects are put into the map when either
> a) a session is created on that node.
> b) a clustered session's presence is requested on that node
>
> I hope that makes sense. Please ask me to explain better if it doesn't.
>
> As we're about to do a Jetty release, I've had to branch the jetty code
> to make some minor mods to the AbstractSessionManager$Session class
> (simply just to change the scope of it's data members to "protected").
>
>
> So the instructions for testing out jetty in terracotta are now as
> follows:
>
> 1. Check out jetty from
> https://svn.codehaus.org/jetty/jetty/branches/terracotta
> 2. Build it with "mvn clean install" at the top level
>
> 3. Check out the jetty-terracotta integration code as part of jetty-
> contrib
>   at
https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
> 4. Build it with "mvn clean install" at the top level
> 5. Copy the target/terracotta-sessions-6.1-SNAPSHOT.jar into the lib/ext
>   directory of the jetty you built in step 1.
>
> 6. Build terracotta with the jetty module changes in it and make a
bootjar

>
> 7. Use the tc-config.xml file from the jetty-contrib/extras/terracotta
>    project to start the tc server
>
> 8. Copy the jetty-contrib/extras/terracotta/src/resources/terracotta-
> test.xml
>    file into the contexts/ directory of the jetty server you built in
> step1.
>
> 9. Start a jetty instance with terracotta:
>
>  java -Dtc.install-root=$TC_HOME \
>  -Xbootclasspath/p:[location-of-boot-jar] \
>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar
>
>
> I've been testing this by turning off session cookies in my browser
> (forcing
> the use of url rewriting) and using the test application's session dump
> servlet to create servlets, add/remove attribute values. The servlet is
> available at: http://localhost:8080/terracottatest/session (or just
click

> on the "Session Dump" link from the page at
> http://localhost:8080/terracottatest).
>
> I've created a second Jetty instance running on the same machine at a
> different
> port number. I've checked that in at jetty-
> contrib/extras/terracotta/src/resources/other-jetty.xml.
> Use it by copying it to your etc/ directory in your jetty instance, then
> naming it on
> the command line when starting the second instance:
>
>  java -Dtc.install-root=$TC_HOME \
>  -Xbootclasspath/p:[location-of-boot-jar] \
>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar \
>   etc/other-jetty.xml
>
>
> So, you should be able to create a session at
> http://localhost:8080/terracottatest/session,
> then cut and paste the url with the jsessionid you get back into a
second
> window/tab of
> your browser and change the port number to 8181 and see the same
session.
>
> I've tested that session attribute setting/removes and session
> invalidation is
> reflected across both instances, but I have yet to test that session
> scavenging
> works.
>
> If you have a test bed where you could run up multiple jetty instances
on
> multiple
> machines (and use cookies for sessions) that would be a big help.
>
> Any comments/suggestions on the code would be very welcome.
>
> cheers
> Jan


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: jetty/terracotta

jan_bartel
Hi Tim,

Yes, the cargo container supports an embedded jetty instance, not an external
one. As a cargo committer, I have to find time to do it - not going to be in
the very near future unfortunately :-(

I've been trying to run the 3 sample wars: Cart, DepartmentTaskList and
Townsend.

I tried first with the DepartmentTaskList and encountered lots of problems
with non-shared objects being put in the Session's attribute map. First I tried
selectively including the classes, but that proved too slow and difficult, so I
changed the tc-config-jetty.xml to be more like the tomcat example - now
 it includes all classes by default and excludes only some:

      <instrumented-classes>

        <include>
          <class-expression>*..*</class-expression>
        </include>
        <exclude>org.mortbay.jetty..*</exclude>
        <exclude>org.apache.jasper..*</exclude>
        <exclude>org.apache.tomcat..*</exclude>

        <include>
          <class-expression>org.mortbay.terracotta..*</class-expression>
        </include>
        <include>
          <class-expression>org.mortbay.terracotta.servlet.TerracottaSessionManager$SessionData</class-expression>
        </include>
      </instrumented-classes>


Unfortunately, now I'm getting odd startup errors. Have you seen anything like
the following or know what might be causing it:

janb@nugget:~/src/jetty-terracotta$ /usr/lib/jvm/jdk1.5.0_09/bin/java -Dtc.install-root=/usr/local/java/terracotta/terracotta-head/code/base/build/dist/terracotta-trunk -Xbootclasspath/p:/home/local/java/terracotta/terracotta-head/code/base/build/homes/tools/dso-boot-hotspot_linux_150_09.jar  -Dtc.config=/home/janb/src/jetty-contrib/extras/terracotta/src/main/resources/tc-config-jetty.xml -jar start.jar
2007-04-22 11:23:55,747 INFO - Terracotta version trunk, as of 20070418-150459 (Revision 2490 by janb@nugget from trunk)
2007-04-22 11:23:56,247 INFO - Configuration loaded from the file at '/home/janb/src/jetty-contrib/extras/terracotta/src/main/resources/tc-config-jetty.xml'.
2007-04-22 11:23:56,364 INFO - Log file: '/home/janb/terracotta/client-logs/terracotta-client.log'.
AW::WARNING - could not load class [org/apache/tools/ant/launch/AntMain] as a resource in loader [StartLoader[file:/home/janb/src/jetty-terracotta/, file:/home/janb/src/jetty-terracotta/lib/jetty-util-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/jetty-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/servlet-api-2.5-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/jsp-api-2.1.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/ant-1.6.5.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/core-3.1.1.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/jsp-2.1.jar, file:/home/janb/src/jetty-terracotta/lib/management/jetty-management-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/management/mx4j-3.0.1.jar, file:/home/janb/src/jetty-terracotta/lib/management/mx4j-tools-3.0.1.jar, file:/home/janb/src/jetty-terracotta/lib/naming/jetty-naming-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/plus/mail-1.4.jar, file:/
home/janb/src/jetty-terracotta/lib/plus/activation-1.1.jar, file:/home/janb/src/jetty-terracotta/lib/plus/jetty-plus-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/xbean/jetty-xbean-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/grizzly/grizzly-1.0.12.jar, file:/home/janb/src/jetty-terracotta/lib/grizzly/jetty-grizzly-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/annotations/geronimo-annotation_1.0_spec-1.0.jar, file:/home/janb/src/jetty-terracotta/lib/annotations/jetty-annotations-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-html-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-servlet-tester-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-sslengine-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-ajp-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-java5-threadpool-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-t
erracotta.jar]]
2007-04-22 11:23:58.472::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
2007-04-22 11:23:58.685::WARN:  Config error at <Set name="ThreadPool">
     
      <New class="org.mortbay.thread.BoundedThreadPool"><Set name="minThreads">10</Set><Set name="maxThreads">250</Set></New>

     
    </Set>
2007-04-22 11:23:58.685::WARN:  EXCEPTION
java.lang.ClassCastException: java.lang.String
        at org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:312)
        at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:237)
        at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:203)
        at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:919)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.mortbay.start.Main.invokeMain(Main.java:183)
        at org.mortbay.start.Main.start(Main.java:497)
        at org.mortbay.start.Main.main(Main.java:115)


thanks!
Jan



Tim Eck wrote:

> I loaded up the latest stuff and tried it out -- seems to be functional
> (p.s. thanks for the detailed setup steps).
>
> As far as testing is concerned, we have a framework of sorts for
> validating distributed sessions. It takes care of spinning up 2+
> Terracotta enabled web containers, a terracotta server and then executing
> the test logic. Wherever possible, the framework uses cargo
> (http://cargo.codehaus.org) to deal with the container specifics. From the
> cargo docs though, it seems like only jetty is only supported for embedded
> use? (we'd want the jetty instances to be standalone java procs). Not a
> big deal, just something we'd have to cook up internally. A few of our
> tests probably depend on details of our session implementation in some
> way, but again we can deal with that.
>
> I think most of the tc-config-jetty.xml can be moved into the jetty module
> that is part of the terracotta distribution (includes, locks and roots). I
> can go ahead and do that if there are no objections.
>
> One tiny little thing I noticed in the code was on lines 133-134 of
> TerracottaSessionIdManager -- It probably doesn't matter, but there is one
> case where the value of "r" will stay negative: Long.MIN_VALUE;
>
>> -----Original Message-----
>> From: Jan Bartel [mailto:[hidden email]]
>> Sent: Thursday, April 19, 2007 7:34 PM
>> To: Discussion for Jetty development.
>> Cc: [hidden email]; Tim Eck
>> Subject: Re: jetty/terracotta
>>
>> At long last I've been able to devote a bit of time to jetty/terracotta
>> integration.
>>
>> Thanks Tim for those mods to the terracotta source to support jetty.
>> They're working a treat.
>>
>> I've changed approach a little to overcome the problem you mentioned
>> with the AbstractSessionManager$Session class. I've created a new
>> class TerracottaSessionManager$SessionData which holds just the
>> information of the session. All the SessionData objects are put
>> into a clustered ConcurrentHashMap. The Session object now delegates
>> to it's corresponding SessionData object. Each TerracottaSessionManager
>> has a (non-clustered) map of Session objects and a clustered map of
>> SessionData objects. Session objects are put into the map when either
>> a) a session is created on that node.
>> b) a clustered session's presence is requested on that node
>>
>> I hope that makes sense. Please ask me to explain better if it doesn't.
>>
>> As we're about to do a Jetty release, I've had to branch the jetty code
>> to make some minor mods to the AbstractSessionManager$Session class
>> (simply just to change the scope of it's data members to "protected").
>>
>>
>> So the instructions for testing out jetty in terracotta are now as
>> follows:
>>
>> 1. Check out jetty from
>> https://svn.codehaus.org/jetty/jetty/branches/terracotta
>> 2. Build it with "mvn clean install" at the top level
>>
>> 3. Check out the jetty-terracotta integration code as part of jetty-
>> contrib
>>   at
> https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
>> 4. Build it with "mvn clean install" at the top level
>> 5. Copy the target/terracotta-sessions-6.1-SNAPSHOT.jar into the lib/ext
>>   directory of the jetty you built in step 1.
>>
>> 6. Build terracotta with the jetty module changes in it and make a
> bootjar
>> 7. Use the tc-config.xml file from the jetty-contrib/extras/terracotta
>>    project to start the tc server
>>
>> 8. Copy the jetty-contrib/extras/terracotta/src/resources/terracotta-
>> test.xml
>>    file into the contexts/ directory of the jetty server you built in
>> step1.
>>
>> 9. Start a jetty instance with terracotta:
>>
>>  java -Dtc.install-root=$TC_HOME \
>>  -Xbootclasspath/p:[location-of-boot-jar] \
>>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar
>>
>>
>> I've been testing this by turning off session cookies in my browser
>> (forcing
>> the use of url rewriting) and using the test application's session dump
>> servlet to create servlets, add/remove attribute values. The servlet is
>> available at: http://localhost:8080/terracottatest/session (or just
> click
>> on the "Session Dump" link from the page at
>> http://localhost:8080/terracottatest).
>>
>> I've created a second Jetty instance running on the same machine at a
>> different
>> port number. I've checked that in at jetty-
>> contrib/extras/terracotta/src/resources/other-jetty.xml.
>> Use it by copying it to your etc/ directory in your jetty instance, then
>> naming it on
>> the command line when starting the second instance:
>>
>>  java -Dtc.install-root=$TC_HOME \
>>  -Xbootclasspath/p:[location-of-boot-jar] \
>>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar \
>>   etc/other-jetty.xml
>>
>>
>> So, you should be able to create a session at
>> http://localhost:8080/terracottatest/session,
>> then cut and paste the url with the jsessionid you get back into a
> second
>> window/tab of
>> your browser and change the port number to 8181 and see the same
> session.
>> I've tested that session attribute setting/removes and session
>> invalidation is
>> reflected across both instances, but I have yet to test that session
>> scavenging
>> works.
>>
>> If you have a test bed where you could run up multiple jetty instances
> on
>> multiple
>> machines (and use cookies for sessions) that would be a big help.
>>
>> Any comments/suggestions on the code would be very welcome.
>>
>> cheers
>> Jan
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: jetty/terracotta

teck-terracotta
That ClassCastException sure is odd -- It is a side effect of the
terracotta instrumentation where we add interfaces to <include>'d classes.
One of the interfaces we ass has a public constant named "TYPE" which
seems to be colliding with the logic in org.mortbay.xml.XmlConfiguration.

To workaround the problem in the short term, you can add these excludes
(below the *..* <include> in your tc-config.xml):

  <exclude>org.mortbay.thread.BoundedThreadPool</exclude>
  <exclude>org.mortbay.component.AbstractLifeCycle</exclude>

Longer term the terracotta code needs to change. We have no need to
pollute the field namespace here, so I think we can just move our
constants. That issue is now tracked here:

  http://jira.terracotta.org/jira/browse/CDV-238

-tim

> -----Original Message-----
> From: Jan Bartel [mailto:[hidden email]]
> Sent: Saturday, April 21, 2007 6:30 PM
> To: Discussion for Jetty development.; Tim Eck
> Cc: [hidden email]
> Subject: Re: jetty/terracotta
>
> Hi Tim,
>
> Yes, the cargo container supports an embedded jetty instance, not an
> external
> one. As a cargo committer, I have to find time to do it - not going to
be
> in
> the very near future unfortunately :-(
>
> I've been trying to run the 3 sample wars: Cart, DepartmentTaskList and
> Townsend.
>
> I tried first with the DepartmentTaskList and encountered lots of
problems
> with non-shared objects being put in the Session's attribute map. First
I
> tried
> selectively including the classes, but that proved too slow and
difficult,

> so I
> changed the tc-config-jetty.xml to be more like the tomcat example - now
>  it includes all classes by default and excludes only some:
>
>       <instrumented-classes>
>
>         <include>
>           <class-expression>*..*</class-expression>
>         </include>
>         <exclude>org.mortbay.jetty..*</exclude>
>         <exclude>org.apache.jasper..*</exclude>
>         <exclude>org.apache.tomcat..*</exclude>
>
>         <include>
>           <class-expression>org.mortbay.terracotta..*</class-expression>
>         </include>
>         <include>
>           <class-
>
expression>org.mortbay.terracotta.servlet.TerracottaSessionManager$Session
> Data</class-expression>
>         </include>
>       </instrumented-classes>
>
>
> Unfortunately, now I'm getting odd startup errors. Have you seen
anything

> like
> the following or know what might be causing it:
>
> janb@nugget:~/src/jetty-terracotta$ /usr/lib/jvm/jdk1.5.0_09/bin/java -
> Dtc.install-root=/usr/local/java/terracotta/terracotta-
> head/code/base/build/dist/terracotta-trunk -
> Xbootclasspath/p:/home/local/java/terracotta/terracotta-
> head/code/base/build/homes/tools/dso-boot-hotspot_linux_150_09.jar  -
> Dtc.config=/home/janb/src/jetty-
> contrib/extras/terracotta/src/main/resources/tc-config-jetty.xml -jar
> start.jar
> 2007-04-22 11:23:55,747 INFO - Terracotta version trunk, as of 20070418-
> 150459 (Revision 2490 by janb@nugget from trunk)
> 2007-04-22 11:23:56,247 INFO - Configuration loaded from the file at
> '/home/janb/src/jetty-contrib/extras/terracotta/src/main/resources/tc-
> config-jetty.xml'.
> 2007-04-22 11:23:56,364 INFO - Log file: '/home/janb/terracotta/client-
> logs/terracotta-client.log'.
> AW::WARNING - could not load class [org/apache/tools/ant/launch/AntMain]
> as a resource in loader [StartLoader[file:/home/janb/src/jetty-
> terracotta/, file:/home/janb/src/jetty-terracotta/lib/jetty-util-6.1-
> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/jetty-6.1-
> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/servlet-api-2.5-
> 6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/jsp-
> api-2.1.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/ant-
> 1.6.5.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/core-
> 3.1.1.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/jsp-2.1.jar,
>
file:/home/janb/src/jetty-terracotta/lib/management/jetty-management-6.1-
> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/management/mx4j-
> 3.0.1.jar,
file:/home/janb/src/jetty-terracotta/lib/management/mx4j-tools-
> 3.0.1.jar, file:/home/janb/src/jetty-terracotta/lib/naming/jetty-naming-
> 6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/plus/mail-
> 1.4.jar, file:/
> home/janb/src/jetty-terracotta/lib/plus/activation-1.1.jar,
>
file:/home/janb/src/jetty-terracotta/lib/plus/jetty-plus-6.1-SNAPSHOT.jar,
> file:/home/janb/src/jetty-terracotta/lib/xbean/jetty-xbean-6.1-
> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/grizzly/grizzly-
> 1.0.12.jar, file:/home/janb/src/jetty-terracotta/lib/grizzly/jetty-
> grizzly-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-
> terracotta/lib/annotations/geronimo-annotation_1.0_spec-1.0.jar,
> file:/home/janb/src/jetty-terracotta/lib/annotations/jetty-annotations-
> 6.1-SNAPSHOT.jar,
file:/home/janb/src/jetty-terracotta/lib/ext/jetty-html-

> 6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-
> servlet-tester-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-
> terracotta/lib/ext/jetty-sslengine-6.1-SNAPSHOT.jar,
> file:/home/janb/src/jetty-terracotta/lib/ext/jetty-ajp-6.1-SNAPSHOT.jar,
> file:/home/janb/src/jetty-terracotta/lib/ext/jetty-java5-threadpool-6.1-
> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-t
> erracotta.jar]]
> 2007-04-22 11:23:58.472::INFO:  Logging to STDERR via
> org.mortbay.log.StdErrLog
> 2007-04-22 11:23:58.685::WARN:  Config error at <Set name="ThreadPool">
>
>       <New class="org.mortbay.thread.BoundedThreadPool"><Set
> name="minThreads">10</Set><Set name="maxThreads">250</Set></New>
>
>
>     </Set>
> 2007-04-22 11:23:58.685::WARN:  EXCEPTION
> java.lang.ClassCastException: java.lang.String
>         at
org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:312)
>         at
> org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:237)
>         at
> org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:203)
>         at
> org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:919)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
>         at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm

> pl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.mortbay.start.Main.invokeMain(Main.java:183)
>         at org.mortbay.start.Main.start(Main.java:497)
>         at org.mortbay.start.Main.main(Main.java:115)
>
>
> thanks!
> Jan
>
>
>
> Tim Eck wrote:
> > I loaded up the latest stuff and tried it out -- seems to be
functional

> > (p.s. thanks for the detailed setup steps).
> >
> > As far as testing is concerned, we have a framework of sorts for
> > validating distributed sessions. It takes care of spinning up 2+
> > Terracotta enabled web containers, a terracotta server and then
> executing
> > the test logic. Wherever possible, the framework uses cargo
> > (http://cargo.codehaus.org) to deal with the container specifics. From
> the
> > cargo docs though, it seems like only jetty is only supported for
> embedded
> > use? (we'd want the jetty instances to be standalone java procs). Not
a
> > big deal, just something we'd have to cook up internally. A few of our
> > tests probably depend on details of our session implementation in some
> > way, but again we can deal with that.
> >
> > I think most of the tc-config-jetty.xml can be moved into the jetty
> module
> > that is part of the terracotta distribution (includes, locks and
roots).

> I
> > can go ahead and do that if there are no objections.
> >
> > One tiny little thing I noticed in the code was on lines 133-134 of
> > TerracottaSessionIdManager -- It probably doesn't matter, but there is
> one
> > case where the value of "r" will stay negative: Long.MIN_VALUE;
> >
> >> -----Original Message-----
> >> From: Jan Bartel [mailto:[hidden email]]
> >> Sent: Thursday, April 19, 2007 7:34 PM
> >> To: Discussion for Jetty development.
> >> Cc: [hidden email]; Tim Eck
> >> Subject: Re: jetty/terracotta
> >>
> >> At long last I've been able to devote a bit of time to
jetty/terracotta

> >> integration.
> >>
> >> Thanks Tim for those mods to the terracotta source to support jetty.
> >> They're working a treat.
> >>
> >> I've changed approach a little to overcome the problem you mentioned
> >> with the AbstractSessionManager$Session class. I've created a new
> >> class TerracottaSessionManager$SessionData which holds just the
> >> information of the session. All the SessionData objects are put
> >> into a clustered ConcurrentHashMap. The Session object now delegates
> >> to it's corresponding SessionData object. Each
TerracottaSessionManager
> >> has a (non-clustered) map of Session objects and a clustered map of
> >> SessionData objects. Session objects are put into the map when either
> >> a) a session is created on that node.
> >> b) a clustered session's presence is requested on that node
> >>
> >> I hope that makes sense. Please ask me to explain better if it
doesn't.
> >>
> >> As we're about to do a Jetty release, I've had to branch the jetty
code
> >> to make some minor mods to the AbstractSessionManager$Session class
> >> (simply just to change the scope of it's data members to
"protected").

> >>
> >>
> >> So the instructions for testing out jetty in terracotta are now as
> >> follows:
> >>
> >> 1. Check out jetty from
> >> https://svn.codehaus.org/jetty/jetty/branches/terracotta
> >> 2. Build it with "mvn clean install" at the top level
> >>
> >> 3. Check out the jetty-terracotta integration code as part of jetty-
> >> contrib
> >>   at
> > https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
> >> 4. Build it with "mvn clean install" at the top level
> >> 5. Copy the target/terracotta-sessions-6.1-SNAPSHOT.jar into the
> lib/ext
> >>   directory of the jetty you built in step 1.
> >>
> >> 6. Build terracotta with the jetty module changes in it and make a
> > bootjar
> >> 7. Use the tc-config.xml file from the
jetty-contrib/extras/terracotta

> >>    project to start the tc server
> >>
> >> 8. Copy the jetty-contrib/extras/terracotta/src/resources/terracotta-
> >> test.xml
> >>    file into the contexts/ directory of the jetty server you built in
> >> step1.
> >>
> >> 9. Start a jetty instance with terracotta:
> >>
> >>  java -Dtc.install-root=$TC_HOME \
> >>  -Xbootclasspath/p:[location-of-boot-jar] \
> >>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar
> >>
> >>
> >> I've been testing this by turning off session cookies in my browser
> >> (forcing
> >> the use of url rewriting) and using the test application's session
dump
> >> servlet to create servlets, add/remove attribute values. The servlet
is

> >> available at: http://localhost:8080/terracottatest/session (or just
> > click
> >> on the "Session Dump" link from the page at
> >> http://localhost:8080/terracottatest).
> >>
> >> I've created a second Jetty instance running on the same machine at a
> >> different
> >> port number. I've checked that in at jetty-
> >> contrib/extras/terracotta/src/resources/other-jetty.xml.
> >> Use it by copying it to your etc/ directory in your jetty instance,
> then
> >> naming it on
> >> the command line when starting the second instance:
> >>
> >>  java -Dtc.install-root=$TC_HOME \
> >>  -Xbootclasspath/p:[location-of-boot-jar] \
> >>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar \
> >>   etc/other-jetty.xml
> >>
> >>
> >> So, you should be able to create a session at
> >> http://localhost:8080/terracottatest/session,
> >> then cut and paste the url with the jsessionid you get back into a
> > second
> >> window/tab of
> >> your browser and change the port number to 8181 and see the same
> > session.
> >> I've tested that session attribute setting/removes and session
> >> invalidation is
> >> reflected across both instances, but I have yet to test that session
> >> scavenging
> >> works.
> >>
> >> If you have a test bed where you could run up multiple jetty
instances

> > on
> >> multiple
> >> machines (and use cookies for sessions) that would be a big help.
> >>
> >> Any comments/suggestions on the code would be very welcome.
> >>
> >> cheers
> >> Jan
> >
> >
> >
------------------------------------------------------------------------
> -
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: jetty/terracotta

jan_bartel
Tim,

Thanks for that! Using your workaround, I can progress the deployment
much further ...

... only to run into another little problem. When hitting the Cart
webapp, I get this:

com.tc.object.tx.UnlockedSharedObjectException:
    Caused by Thread: btpool0-2  in  VM(0)
    Shared Object Type: demo.cart.DummyCart
        at com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransactionManagerImpl.java:254)
        at com.tc.object.tx.ClientTransactionManagerImpl.fieldChanged(ClientTransactionManagerImpl.java:504)
        at com.tc.object.TCObjectImpl.objectFieldChanged(TCObjectImpl.java:282)
        at demo.cart.DummyCart.__tc_setsubmit(Unknown Source)
        at demo.cart.DummyCart.reset(Unknown Source)
        at demo.cart.DummyCart.processRequest(Unknown Source)
        at org.apache.jsp.carts_jsp._jspService(org.apache.jsp.carts_jsp:75)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:80)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:464)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:358)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        [snip]

I've added these lines to the tc-config.xml file to no avail:

        <autolock>
          <method-expression>* demo.*.*(..)</method-expression>
          <lock-level>write</lock-level>
        </autolock>

Please excuse my ignorance of the syntax of these locking expressions, but I
was pretty sure that my change above would have fixed things, but it doesn't :-(
Any ideas on what I need to do to make this work?


thanks in advance,
Jan


Tim Eck wrote:

> That ClassCastException sure is odd -- It is a side effect of the
> terracotta instrumentation where we add interfaces to <include>'d classes.
> One of the interfaces we ass has a public constant named "TYPE" which
> seems to be colliding with the logic in org.mortbay.xml.XmlConfiguration.
>
> To workaround the problem in the short term, you can add these excludes
> (below the *..* <include> in your tc-config.xml):
>
>   <exclude>org.mortbay.thread.BoundedThreadPool</exclude>
>   <exclude>org.mortbay.component.AbstractLifeCycle</exclude>
>
> Longer term the terracotta code needs to change. We have no need to
> pollute the field namespace here, so I think we can just move our
> constants. That issue is now tracked here:
>
>   http://jira.terracotta.org/jira/browse/CDV-238
>
> -tim
>
>> -----Original Message-----
>> From: Jan Bartel [mailto:[hidden email]]
>> Sent: Saturday, April 21, 2007 6:30 PM
>> To: Discussion for Jetty development.; Tim Eck
>> Cc: [hidden email]
>> Subject: Re: jetty/terracotta
>>
>> Hi Tim,
>>
>> Yes, the cargo container supports an embedded jetty instance, not an
>> external
>> one. As a cargo committer, I have to find time to do it - not going to
> be
>> in
>> the very near future unfortunately :-(
>>
>> I've been trying to run the 3 sample wars: Cart, DepartmentTaskList and
>> Townsend.
>>
>> I tried first with the DepartmentTaskList and encountered lots of
> problems
>> with non-shared objects being put in the Session's attribute map. First
> I
>> tried
>> selectively including the classes, but that proved too slow and
> difficult,
>> so I
>> changed the tc-config-jetty.xml to be more like the tomcat example - now
>>  it includes all classes by default and excludes only some:
>>
>>       <instrumented-classes>
>>
>>         <include>
>>           <class-expression>*..*</class-expression>
>>         </include>
>>         <exclude>org.mortbay.jetty..*</exclude>
>>         <exclude>org.apache.jasper..*</exclude>
>>         <exclude>org.apache.tomcat..*</exclude>
>>
>>         <include>
>>           <class-expression>org.mortbay.terracotta..*</class-expression>
>>         </include>
>>         <include>
>>           <class-
>>
> expression>org.mortbay.terracotta.servlet.TerracottaSessionManager$Session
>> Data</class-expression>
>>         </include>
>>       </instrumented-classes>
>>
>>
>> Unfortunately, now I'm getting odd startup errors. Have you seen
> anything
>> like
>> the following or know what might be causing it:
>>
>> janb@nugget:~/src/jetty-terracotta$ /usr/lib/jvm/jdk1.5.0_09/bin/java -
>> Dtc.install-root=/usr/local/java/terracotta/terracotta-
>> head/code/base/build/dist/terracotta-trunk -
>> Xbootclasspath/p:/home/local/java/terracotta/terracotta-
>> head/code/base/build/homes/tools/dso-boot-hotspot_linux_150_09.jar  -
>> Dtc.config=/home/janb/src/jetty-
>> contrib/extras/terracotta/src/main/resources/tc-config-jetty.xml -jar
>> start.jar
>> 2007-04-22 11:23:55,747 INFO - Terracotta version trunk, as of 20070418-
>> 150459 (Revision 2490 by janb@nugget from trunk)
>> 2007-04-22 11:23:56,247 INFO - Configuration loaded from the file at
>> '/home/janb/src/jetty-contrib/extras/terracotta/src/main/resources/tc-
>> config-jetty.xml'.
>> 2007-04-22 11:23:56,364 INFO - Log file: '/home/janb/terracotta/client-
>> logs/terracotta-client.log'.
>> AW::WARNING - could not load class [org/apache/tools/ant/launch/AntMain]
>> as a resource in loader [StartLoader[file:/home/janb/src/jetty-
>> terracotta/, file:/home/janb/src/jetty-terracotta/lib/jetty-util-6.1-
>> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/jetty-6.1-
>> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/servlet-api-2.5-
>> 6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/jsp-
>> api-2.1.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/ant-
>> 1.6.5.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/core-
>> 3.1.1.jar, file:/home/janb/src/jetty-terracotta/lib/jsp-2.1/jsp-2.1.jar,
>>
> file:/home/janb/src/jetty-terracotta/lib/management/jetty-management-6.1-
>> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/management/mx4j-
>> 3.0.1.jar,
> file:/home/janb/src/jetty-terracotta/lib/management/mx4j-tools-
>> 3.0.1.jar, file:/home/janb/src/jetty-terracotta/lib/naming/jetty-naming-
>> 6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/plus/mail-
>> 1.4.jar, file:/
>> home/janb/src/jetty-terracotta/lib/plus/activation-1.1.jar,
>>
> file:/home/janb/src/jetty-terracotta/lib/plus/jetty-plus-6.1-SNAPSHOT.jar,
>> file:/home/janb/src/jetty-terracotta/lib/xbean/jetty-xbean-6.1-
>> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/grizzly/grizzly-
>> 1.0.12.jar, file:/home/janb/src/jetty-terracotta/lib/grizzly/jetty-
>> grizzly-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-
>> terracotta/lib/annotations/geronimo-annotation_1.0_spec-1.0.jar,
>> file:/home/janb/src/jetty-terracotta/lib/annotations/jetty-annotations-
>> 6.1-SNAPSHOT.jar,
> file:/home/janb/src/jetty-terracotta/lib/ext/jetty-html-
>> 6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-
>> servlet-tester-6.1-SNAPSHOT.jar, file:/home/janb/src/jetty-
>> terracotta/lib/ext/jetty-sslengine-6.1-SNAPSHOT.jar,
>> file:/home/janb/src/jetty-terracotta/lib/ext/jetty-ajp-6.1-SNAPSHOT.jar,
>> file:/home/janb/src/jetty-terracotta/lib/ext/jetty-java5-threadpool-6.1-
>> SNAPSHOT.jar, file:/home/janb/src/jetty-terracotta/lib/ext/jetty-t
>> erracotta.jar]]
>> 2007-04-22 11:23:58.472::INFO:  Logging to STDERR via
>> org.mortbay.log.StdErrLog
>> 2007-04-22 11:23:58.685::WARN:  Config error at <Set name="ThreadPool">
>>
>>       <New class="org.mortbay.thread.BoundedThreadPool"><Set
>> name="minThreads">10</Set><Set name="maxThreads">250</Set></New>
>>
>>
>>     </Set>
>> 2007-04-22 11:23:58.685::WARN:  EXCEPTION
>> java.lang.ClassCastException: java.lang.String
>>         at
> org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:312)
>>         at
>> org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:237)
>>         at
>> org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:203)
>>         at
>> org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:919)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at
>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 39)
>>         at
>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
>> pl.java:25)
>>         at java.lang.reflect.Method.invoke(Method.java:585)
>>         at org.mortbay.start.Main.invokeMain(Main.java:183)
>>         at org.mortbay.start.Main.start(Main.java:497)
>>         at org.mortbay.start.Main.main(Main.java:115)
>>
>>
>> thanks!
>> Jan
>>
>>
>>
>> Tim Eck wrote:
>>> I loaded up the latest stuff and tried it out -- seems to be
> functional
>>> (p.s. thanks for the detailed setup steps).
>>>
>>> As far as testing is concerned, we have a framework of sorts for
>>> validating distributed sessions. It takes care of spinning up 2+
>>> Terracotta enabled web containers, a terracotta server and then
>> executing
>>> the test logic. Wherever possible, the framework uses cargo
>>> (http://cargo.codehaus.org) to deal with the container specifics. From
>> the
>>> cargo docs though, it seems like only jetty is only supported for
>> embedded
>>> use? (we'd want the jetty instances to be standalone java procs). Not
> a
>>> big deal, just something we'd have to cook up internally. A few of our
>>> tests probably depend on details of our session implementation in some
>>> way, but again we can deal with that.
>>>
>>> I think most of the tc-config-jetty.xml can be moved into the jetty
>> module
>>> that is part of the terracotta distribution (includes, locks and
> roots).
>> I
>>> can go ahead and do that if there are no objections.
>>>
>>> One tiny little thing I noticed in the code was on lines 133-134 of
>>> TerracottaSessionIdManager -- It probably doesn't matter, but there is
>> one
>>> case where the value of "r" will stay negative: Long.MIN_VALUE;
>>>
>>>> -----Original Message-----
>>>> From: Jan Bartel [mailto:[hidden email]]
>>>> Sent: Thursday, April 19, 2007 7:34 PM
>>>> To: Discussion for Jetty development.
>>>> Cc: [hidden email]; Tim Eck
>>>> Subject: Re: jetty/terracotta
>>>>
>>>> At long last I've been able to devote a bit of time to
> jetty/terracotta
>>>> integration.
>>>>
>>>> Thanks Tim for those mods to the terracotta source to support jetty.
>>>> They're working a treat.
>>>>
>>>> I've changed approach a little to overcome the problem you mentioned
>>>> with the AbstractSessionManager$Session class. I've created a new
>>>> class TerracottaSessionManager$SessionData which holds just the
>>>> information of the session. All the SessionData objects are put
>>>> into a clustered ConcurrentHashMap. The Session object now delegates
>>>> to it's corresponding SessionData object. Each
> TerracottaSessionManager
>>>> has a (non-clustered) map of Session objects and a clustered map of
>>>> SessionData objects. Session objects are put into the map when either
>>>> a) a session is created on that node.
>>>> b) a clustered session's presence is requested on that node
>>>>
>>>> I hope that makes sense. Please ask me to explain better if it
> doesn't.
>>>> As we're about to do a Jetty release, I've had to branch the jetty
> code
>>>> to make some minor mods to the AbstractSessionManager$Session class
>>>> (simply just to change the scope of it's data members to
> "protected").
>>>>
>>>> So the instructions for testing out jetty in terracotta are now as
>>>> follows:
>>>>
>>>> 1. Check out jetty from
>>>> https://svn.codehaus.org/jetty/jetty/branches/terracotta
>>>> 2. Build it with "mvn clean install" at the top level
>>>>
>>>> 3. Check out the jetty-terracotta integration code as part of jetty-
>>>> contrib
>>>>   at
>>> https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta
>>>> 4. Build it with "mvn clean install" at the top level
>>>> 5. Copy the target/terracotta-sessions-6.1-SNAPSHOT.jar into the
>> lib/ext
>>>>   directory of the jetty you built in step 1.
>>>>
>>>> 6. Build terracotta with the jetty module changes in it and make a
>>> bootjar
>>>> 7. Use the tc-config.xml file from the
> jetty-contrib/extras/terracotta
>>>>    project to start the tc server
>>>>
>>>> 8. Copy the jetty-contrib/extras/terracotta/src/resources/terracotta-
>>>> test.xml
>>>>    file into the contexts/ directory of the jetty server you built in
>>>> step1.
>>>>
>>>> 9. Start a jetty instance with terracotta:
>>>>
>>>>  java -Dtc.install-root=$TC_HOME \
>>>>  -Xbootclasspath/p:[location-of-boot-jar] \
>>>>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar
>>>>
>>>>
>>>> I've been testing this by turning off session cookies in my browser
>>>> (forcing
>>>> the use of url rewriting) and using the test application's session
> dump
>>>> servlet to create servlets, add/remove attribute values. The servlet
> is
>>>> available at: http://localhost:8080/terracottatest/session (or just
>>> click
>>>> on the "Session Dump" link from the page at
>>>> http://localhost:8080/terracottatest).
>>>>
>>>> I've created a second Jetty instance running on the same machine at a
>>>> different
>>>> port number. I've checked that in at jetty-
>>>> contrib/extras/terracotta/src/resources/other-jetty.xml.
>>>> Use it by copying it to your etc/ directory in your jetty instance,
>> then
>>>> naming it on
>>>> the command line when starting the second instance:
>>>>
>>>>  java -Dtc.install-root=$TC_HOME \
>>>>  -Xbootclasspath/p:[location-of-boot-jar] \
>>>>  -Dtc.config=[location-of-tc-config-jetty.xml] -jar start.jar \
>>>>   etc/other-jetty.xml
>>>>
>>>>
>>>> So, you should be able to create a session at
>>>> http://localhost:8080/terracottatest/session,
>>>> then cut and paste the url with the jsessionid you get back into a
>>> second
>>>> window/tab of
>>>> your browser and change the port number to 8181 and see the same
>>> session.
>>>> I've tested that session attribute setting/removes and session
>>>> invalidation is
>>>> reflected across both instances, but I have yet to test that session
>>>> scavenging
>>>> works.
>>>>
>>>> If you have a test bed where you could run up multiple jetty
> instances
>>> on
>>>> multiple
>>>> machines (and use cookies for sessions) that would be a big help.
>>>>
>>>> Any comments/suggestions on the code would be very welcome.
>>>>
>>>> cheers
>>>> Jan
>>>
>>>
> ------------------------------------------------------------------------
>> -
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2 express and take
>>> control of your XML. No limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
12