struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <>
Subject Re: DownloadAction Application
Date Mon, 07 Mar 2005 20:22:55 GMT
See within:

On Mon, 7 Mar 2005 15:06:08 -0500 (EST), Frank W. Zammetti
<> wrote:
> That's kinda cool, but I have a question... How would such a thing work in
> a clustered environment?

See within:

> I presume a browser starts an upload and you simultaneously open a new
> window that will periodically communicate with this monitor class to check
> the status of the file being uploaded.  Do I have at least THAT much
> right?? :)

Yes.  Thats right.  The monitoring is happening within the internals
of the output stream, in the read(...) method, as previously
indicated.  This is all taking place in the session, and so long as
you have access to the session, you can get the data needed.  Note
that the check is via a Struts Action.

> 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?
There is nothing that keeps you from monitoring upload to a database,
which of course is actually on a file system, as is anything else not
in memory.  Just overwrite store(...) in Upload to include a database
as an option.  I took this out of what is provided to the Struts wiki
for security reasons.

I get a kick out of this way of putting things, by the way.  In regard
to clustering: databases are, after all, also on a file system.  Just
a usually a separate one in clustered environments.  But, you could
also have a separate one for plain old files too.  But, I know what
you mean.

> The only answer I can think of is to assume that each server in the
> cluster has a mapping to some common shared drive where the uploads are
> written to, but that is assuming something about the deployment
> environment, and something I know for sure would never happen where I
> work.

How do you handle references to uploads now?  That is the only issue
really, right?  If you see how you do that, then just do that.  That
is the only issue, right?  Don't you have a way for people within a
session to see what happens to their file uploads?


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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message