struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: AW: DownloadAction Application
Date Mon, 07 Mar 2005 20:33:08 GMT
Actually, Leon, I think it is really relevant and important to struts
uploading.  The point I was trying to make, however, and I think you
will agree, is that there has to be somewhere you put the files if you
allow uploading and there has to be some output stream doing it.  That
means you can monitor no matter what you do, right?

Jack


On Mon, 7 Mar 2005 21:22:52 +0100, Leon Rosenberg
<struts_user@anotheria.net> wrote:
> That depends. Ok, if you distribute the session, well, then you probably
> don't need a clustered environment,
> but a  doctor :-) I mean, one of the goals of the clustering is performance,
> and write something in the
> database on _each_ request is the best performance killer :-)
> 
> If performance is not an issue, you can mount same filesystem on each
> webserver, and check the progress on
> the filesystem.
> 
> At my current project, we are hosting on 12 machines with session
> persistence. This means, that if a machine
> crashes all users logged in onto this server has to relogin. So far it
> happened 5 times (I curse tomcat) in last 6 month. I think it's ok for most
> users / websites. Most of our users didn't noticed it or blamed the
> DSL-provider
> or the browser (which is always a good point for flames, by default:-))
> 
> But I think this is getting far far far off topic...
> 
> Regards
> Leon
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> > Gesendet: Montag, 7. März 2005 21:14
> > An: Struts Users Mailing List
> > Betreff: Re: AW: DownloadAction Application
> >
> > Is that the way it works in your environment Leon?  Its not
> > the way it works here :)  Or any other clustered environment
> > I've ever worked in.
> >
> > I mean, the express purpose of a clustered environment is to
> > distribute load.  If a user hits one server for one request,
> > but then upon making the second request that server they hit
> > the first time is loaded down, the whole point of the cluster
> > (ignoring failover and such of course) is to get that user to
> > a less loaded server so that all users have a good response
> > time on average.
> >
> > That's also the reason IBM tells you to keep session small:
> > it has to be replicated across the cluster so that any
> > request can be serviced by any machine in the cluster at any
> > given time.
> >
> > That's not to say you COULDN'T configure things to always
> > direct a user to a given server.  But I think that defeats
> > the purpose of such an environment :)
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> > On Mon, March 7, 2005 3:05 pm, Leon Rosenberg said:
> > >> Assuming so... in a clustered environment, first of all,
> > writing to
> > >> the file system is generally discouraged practice
> > (although it can be
> > >> done safely, so let's ignore what might be best practice for the
> > >> moment)... but if you do so, since the upload may start on
> > one server
> > >> and then the monitor gets executed on any server in the
> > cluster with
> > >> each subsequent check operation, how does that get handled?
> > >
> > > The loadbalancer should send all requests from one user to same
> > > server, so it's not an issue.
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message