Hey,
Is Jetty going to become a part of JBoss? Just asking. That would be very
cool and make JBoss a true J2ee impl.
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Saturday, September 01, 2001 4:08 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] RE: Persistant HttpSession
>
>
> For some reason this thread is not repling to the list correctly.
>
> I think that no matter what you do, if you want a persistent session you
> need to send the data off server and the off server location, and
> this means
> serialization and network traffic (unavoidable in all cases). As for
> waiting for the db (which is just a file system in the basic
> case), this is
> avoidable if you use a multicast system. The tradeoff is that each server
> listening to the multicast must process the messages. In a crapy
> implementation you get an n-to-the-n star network problem (you
> don't get n^n
> connections but each server has to process the messages from the n other
> servers).
>
> The real answear the marc presented stands. There a billion possible
> solutions and each one has different performance problems. What we in the
> jboss group must do is define an interface to allow most (if not all)
> implementaions.
>
> Is there an interface for HttpSession persistence in the web container
> layer?
>
> -dain
>
> > -----Original Message-----
> > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, September 01, 2001 2:50 PM
> > To: Dain Sundstrom
> > Subject: Re: [JBoss-dev] RE: Persistant HttpSession
> >
> >
> > Just as IBM WebSphere is doing. But the problem is that
> > you introduce the latency of the network and DB for a regular
> > simple task.
> > On the other side your fail-over and clustering is reduced
> > to the one of the DB which can not become the bottleneck.
> >
> > Andy
> >
> > ----- Original Message -----
> > From: "Dain Sundstrom" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, September 01, 2001 12:19 PM
> > Subject: FW: [JBoss-dev] RE: Persistant HttpSession
> >
> >
> > > I ment to send this to the list, but hit the wrong button.
> > >
> > > -----Original Message-----
> > > From: Dain Sundstrom
> > > Sent: Saturday, September 01, 2001 10:20 AM
> > > To: 'Julian Gosnell'
> > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession
> > >
> > >
> > > I saw a presentation at JavaOne from HP on thier highly scaleable
> > > architecture and they were storing the http sessions into a
> > db after each
> > > request. The trick was they used a seperate database just
> > for storing the
> > > http session and this db was highly tuned for this type of
> > use. With this
> > > type of architecture you could tune the system to have a
> > minimal impact
> > from
> > > the session storage. (As a side note if you know the
> > structure of the http
> > > session you could make is very fast).
> > >
> > > -dain
> > >
> > > > -----Original Message-----
> > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
> > > > Sent: Saturday, September 01, 2001 9:47 AM
> > > > To: Bill Burke
> > > > Cc: Kevin Duffey; Greg Wilkins;
> > > > [EMAIL PROTECTED];
> > > > [EMAIL PROTECTED]
> > > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession
> > > >
> > > >
> > > >
> > > > I understand what you are saying, Bill.
> > > >
> > > > I am not proposing this as an enterprise level solution.
> > > > I am proposing it as a full-featured (distributed/persistant)
> > > > but trivial
> > > > implementation.
> > > > This means we can get it done quickly. More quickly than
> > > > perhaps Kevin might
> > > > get his solution implemented or a JavaGroups solution
> > might get done.
> > > >
> > > > Because it is very simple, it is unlikely to be buggy.
> > > >
> > > > Once we have a rock-solid implementation, we can turn around
> > > > and look at better
> > > > solutions. If you want to write a JavaGroups solution you are
> > > > very welcome to.
> > > > I don't see anything on your website about persistance, which
> > > > I assume is the
> > > > reason why your proposed solution would be faster. However I
> > > > would be surprised
> > > > if it was actually simpler and required less additional
> > > > infrastructure (over
> > > > and above JBoss, because that is the perspective from which I
> > > > am working) than
> > > > a CMP solution.
> > > >
> > > > Besides DB access will only be necessary if a Servlet/JSP
> > > > needs to read/write
> > > > state. This is not the case with every click on a website. If
> > > > the Servlet is
> > > > reading/writing state, then is is probably accessing EJBs
> > too (JBoss
> > > > perspective again), so the cost of one more access may not be
> > > > so unpalatable.
> > > >
> > > > I fully expect CMP to be the slowest solution, but I am not
> > > > going to launch
> > > > myself into a new problem space without a little recce trip
> > > > and that is what my
> > > > CMP HttpSession (If I actually write it) was intended to be -
> > > > sorry if this was
> > > > not made clear.
> > > >
> > > > Distribution may actually be a good enough solution, without
> > > > persistance,
> > > > provided that as new nodes come up they can update themselves
> > > > simply from the
> > > > rest of the cluster. Provided that the whole cluster does not
> > > > go down at once.
> > > >
> > > > With 2 or 3 solutions to the problem we will all be in a
> > > > better situation to
> > > > choose the one that best suits us. It's horses for courses.
> > > >
> > > >
> > > > Cheers,
> > > >
> > > >
> > > >
> > > > Jules
> > > >
> > > >
> > > > Bill Burke wrote:
> > > >
> > > > > Julian,
> > > > >
> > > > > Again, I don't think a CMP Bean is a good idea. You'll be
> > > > writing to the
> > > > > database for every click on your website! This is just not
> > > > scalable at all.
> > > > > Your database will just get flooded with too many requests.
> > > > >
> > > > > Bill
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: jules [mailto:jules]On Behalf Of Julian Gosnell
> > > > > > Sent: Saturday, September 01, 2001 6:05 AM
> > > > > > To: Kevin Duffey
> > > > > > Cc: Greg Wilkins; [EMAIL PROTECTED];
> > > > > > [EMAIL PROTECTED]; Bill Burke
> > > > > > Subject: Re: Persistant HttpSession
> > > > > >
> > > > > >
> > > > > > Here is what I suggest.
> > > > > >
> > > > > > Greg, as Kevin suggests, selects the HttpSession class
> > > > via property or
> > > > > > configuration parameter.
> > > > > >
> > > > > > The current unclustered implementation is the default.
> > > > > >
> > > > > > We put together a list of the features that such a class might
> > > > > > need to offer -
> > > > > > I have the following at the moment:
> > > > > >
> > > > > > Simple - no clustering support
> > > > > > Persistant - changes are remembered
> > > > > > Distributed - changes are replicated across the cluster
> > > > (easier with
> > > > > > persistance)
> > > > > >
> > > > > >
> > > > > > Possible implementations I have so far:
> > > > > >
> > > > > > Simple - already done
> > > > > > Persistant and Distributed - via e.g. a CMP bean, or a
> > > > more complex
> > > > > > implementation which is a bit cleverer
> > > > > > Just Distributed - could use some underlying distribution
> > > > technology,
> > > > > > javaspaces, http://www.javagroups.com/ - faster without
> > > > persistance
> > > > > >
> > > > > > I'm putting my hand up for the CMP bean stuff -
> > unless I think of
> > > > > > an easier
> > > > > > way.
> > > > > >
> > > > > > Looks like Kevin is keen on a faster P&D solution
> > > > > >
> > > > > > Bill might be interested in a JavaGroups Distributed
> > > > implementation ???
> > > > > >
> > > > > >
> > > > > > How does that sound ?
> > > > > >
> > > > > > Can anyone think of any more features that might be needed ?
> > > > > >
> > > > > >
> > > > > > Jules
> > > > > >
> > > > > >
> > > > > > Kevin Duffey wrote:
> > > > > >
> > > > > > > I am not sure I would agree mostly because I personally
> > > > like to design
> > > > > > > things right the first time over getting it out fast. But, I
> > > > > > think we can do
> > > > > > > both. I haven't been able to look at the source yet, but I
> > > > > > imagine if the
> > > > > > > container is configurable to specify what session
> > > > manager to load (via a
> > > > > > > class name perhaps), we can then create one (or more)
> > > > HttpSession
> > > > > > > implementations, each with their own special
> > characteristics.
> > > > > > In this way,
> > > > > > > its pluggable right from the getgo. What we can then do
> > > > is turn Greg's
> > > > > > > existing HttpSession implementation into the
> > "default" class to
> > > > > > be loaded.
> > > > > > > >From there you and I can maybe both create a different
> > > > > > implementation of
> > > > > > > HttpSession that is also pluggable so that Jetty will
> > > > have 3 different
> > > > > > > versions. One that is non clusterable (for single JVM
> > > > use and thus a bit
> > > > > > > more speed), and two that are for clustering.
> > > > > > >
> > > > > > > This is but one way we can maybe go about this. What do
> > > > you two think?
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
> > > > > > > > Sent: Friday, August 31, 2001 5:59 AM
> > > > > > > > To: Greg Wilkins; Julian Gosnell
> > > > > > > > Cc: [EMAIL PROTECTED]
> > > > > > > > Subject: Persistant HttpSession
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > I don't know if it needs to be tied into EJBs?
> > > > > > > > > Depends on how you
> > > > > > > > > design your EJBs I guess.
> > > > > > > >
> > > > > > > > I think an initial naive implementation would probably
> > > > > > > > use EJBs, simply because I'm sitting in an EJB Server,
> > > > > > > > with all the necessary infrastructure for persistance
> > > > > > > > and distribution surrounding me.
> > > > > > > >
> > > > > > > > Only problem is, an EJB is a _STATIC_ wrapper around a
> > > > > > > > dynamic resource (i.e. you can stick new slots into a
> > > > > > > > table at run time, but not into a Java instance),
> > > > > > > > whereas an HttpSession is basically a HashTable, with
> > > > > > > > dynamic runtime structure. So all I will really be
> > > > > > > > doing is having an EJB with one instance data member
> > > > > > > > called HashTable, which contains the serialised (by
> > > > > > > > value) hastable.
> > > > > > > >
> > > > > > > > More complex, intelligent and faster implementations
> > > > > > > > could be thought up afterwards, but I think the
> > > > > > > > initial one should be as simple as possible and out
> > > > > > > > there as quickly as possible, and bug-free.
> > > > > > > >
> > > > > > > > Of course this puts certain constraints on what you
> > > > > > > > can put in your HttpSession - it has to be
> > > > > > > > serialisable - something Sun did not consider when
> > > > > > > > they came up with the HttpSession interface. This
> > > > > > > > means that moving a Servlet from a single node
> > > > > > > > deployment into a cluster may result in a change in
> > > > > > > > behaviour if it is not written according to certain
> > > > > > > > guidelines. I assume Sun must have published something
> > > > > > > > to this effect - I shall have to hunt it down.
> > > > > > > >
> > > > > > > > WebSphere implements one other strategy that gets this
> > > > > > > > done. The Master which dispatches the request to the
> > > > > > > > cluster can be configured to look for a session-id and
> > > > > > > > route requests with the same session-id to the same
> > > > > > > > node. This approach would allow you to deploy those
> > > > > > > > problem Servlets with the standard HttpSession object,
> > > > > > > > and no change in semantics - but then it's not really
> > > > > > > > clustering is it ... just double processing an HTTP
> > > > > > > > request instead of single processing it....
> > > > > > > >
> > > > > > > > Jules
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > ____________________________________________________________
> > > > > > > > Do You Yahoo!?
> > > > > > > > Get your free @yahoo.co.uk address at
> http://mail.yahoo.co.uk
> > > > > > > or your free @yahoo.ie address at http://mail.yahoo.ie
> > > > >
> > > > >
> > > > > _________________________________________________________
> > > > > Do You Yahoo!?
> > > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
