Yes, JavaGroups looks very cool. Sacha Labourey turned me on to this in
his first iteration of HA SLSB. I have yet to see a saturation of a 100M
switched ethernet so I'm skeptical about all the academics screaming about
multicast performance. Would all those Slim Shadys who actually experienced
performance problems with multicast, Please stand up, Please stand up,
please stand up.....
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin
> Duffey
> Sent: Saturday, September 01, 2001 1:23 PM
> To: Bill Burke; marc fleury; Julian Gosnell
> Cc: Greg Wilkins; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] RE: Persistant HttpSession
>
>
> Bill,
>
> Looking at JavaGroups it sounds like it would possibly allow a good
> mechanism for the HttpSession replication as well. My experience is mostly
> with Orion so I have to take my example from what they do. They use
> multicast for HttpSession fail-over, so when I clicked on that link and
> started reading, it sounded like this may be a possible way for
> HttpSession
> replication as well. What do you think? I read a few posts on the Orion
> lists saying that using multicast can hinder network bandwidth
> but I wasn't
> sure why this would be. If you set up x number of servers in a cluster to
> listen on a specific port for replication messages, wouldn't that only use
> one port? I'll have to read up more on multicast. I understand that it
> broadcasts out to potentially x number of listeners, but just not
> sure about
> the semantics of how it works.
>
>
> > -----Original Message-----
> > From: Bill Burke [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, September 01, 2001 10:11 AM
> > To: marc fleury; Julian Gosnell
> > Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] RE: Persistant HttpSession
> >
> >
> > Hey Julian/Marc,
> >
> > I hope didn't sound rude before. I was just pointing out what I
> > think is a
> > serious problem in using CMP.
> >
> > Julian, seriously, take a look at JavaGroups.DistributedHashtable
> > http://www.javagroups.com It is really easy to use, and I think
> > you'll find
> > it really cool.
> >
> > Marc, the inVM thingy you were talking about before is a
> cluster SFSB. I
> > agree that using EJB is a good abstration for this. I know jack
> > squat about
> > Message Driven Beans, but would that be a possibility as well?
> >
> > Regards,
> >
> > Bill
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On
> Behalf Of marc
> > > fleury
> > > Sent: Saturday, September 01, 2001 11:47 AM
> > > To: Julian Gosnell; Bill Burke
> > > Cc: Kevin Duffey; Greg Wilkins;
> [EMAIL PROTECTED];
> > > [EMAIL PROTECTED]
> > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession
> > >
> > >
> > > reading this reply I feel I should say what is on my mind
> > > technologically-wise.
> > >
> > > It seems to me that you are asking for a EJB semantic and we
> > are answering
> > > with "persistence" issues. I think it is symptomatic and goes
> > back to the
> > > larger EJB discussions and particularly the Entity bashing that seems
> > > popular these days.
> > >
> > > They are largely orthogonal issues. You can replace the
> > > persistence engine
> > > in JBoss. We allow for this, if you want A IN VM STORE WITH
> > > REPLICATED JAVA
> > > GROUPS as opposed to database access, WHAT PREVENTS US FROM
> > DOING IT? (JMX
> > > multinode batches of mods :)
> > >
> > > Julian is saying "I can get to work, manhana on this if I use the EJB
> > > patterns". We as JBoss can get to work on this manhana if we
> > isolate the
> > > store work. Isolation. We have divided the work and the
> > implementation of
> > > the store is "irrelevant" from Julian's point of view.
> > >
> > > Bill, you are right, a database solution is probably the worst, but it
> > > should not stop Julian from working until WE come up with a
> great store.
> > > And what really gets me excited is the fact that EJB semantic is
> > > natural and
> > > the implementation is orthogonal... its the trend...
> > >
> > > Another example is the Jive forums... they use direct JDBC because the
> > > persistence blabla and the replication bla bla bla... Same category of
> > > problems the solution is in our camp.
> > >
> > > marcf
> > >
> > > |-----Original Message-----
> > > |From: [EMAIL PROTECTED]
> > > |[mailto:[EMAIL PROTECTED]]On Behalf Of
> > > |Julian Gosnell
> > > |Sent: Saturday, September 01, 2001 10: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
