Case in point: I just migrated an app that was on a single server to the clustered environment... I had an object with a static HashMap in it that stored app config parameters. Pretty typical, and it works in a cluster. Problem is, I had the ability to update those config parameters from within the app at any time. Well, what happens when you do that? You wind up getting on server in the cluster with the new values, the rest with the old values! ARGH!!
Am I correct in my understanding that the monitor that you pull out of session during the subsequent status check requests use the reference to the stream object that it holds to check on the status? If so, I think this is an important point because it will be a limitation of your design where a clustered environment is concerned. Unless, as might in fact be the case, the app server is smart enough to essentially do RMI, or something like that, to allow the monitor to talk to the stream. Again, since you could be talking about communication between JVMs, if the app server doesn't do it for you, and you don't do it, your sunk.
To state is a little more succinclty... the monitor holds a reference to a stream that exists in one particular JVM in the cluster. Any subsequent request that comes in to a different server won't be able to access that stream object EVEN THOUGH it can get the monitor from session, because the reference is invalid since its in another JVM.
If however I am wrong here and the STREAM has a reference to the SESSION object (and thereby the monitor within it), THAT might in fact work just fine. In fact, I can't think of a reason why it wouldn't.
So, we're left with the question we're usually left with: do I understand your design properly or not?!? :)
Frank
Dakota Jack wrote:
This is not my area, Frank, so I am running a bit on the "what things must be like" gas here. A cluster that does not allow you to have objects that can be updated in session would not be of much use. That is why, after all, you put objects in session. And, the fact that this is a file upload should not be that related, since the update is coming from a read in the UploadOutputStream class.
Jack
On Mon, 07 Mar 2005 17:51:44 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Sounds about right :) And like I said before, probably some of my debate comes from not fully understanding what your doing.
But, here's where I have some concern... The upload begins and an UploadOutputStream starts it's thing. A Monitor is created, and holds a reference to the stream? (or is the other way around? I'll assume the monitor references the stream, since that makes more sense in my head). Either way... the monitor gets dumped in session... Now, the main browser window is of course the upload process, the popup window is periodically calling some Action that asks the monitor for a status, which asks the stream about its status. No problem yet...
But... what if those status requests hit a different servet in the cluster? Yes, you can get the reference to the monitor since its in session, but does the reference to the stream in the monitor have any meaning? I suspect it doesn't because it exists in a different JVM at that point. Maybe the app server is a lot smarter than I am giving it credit for, but if not, that's the problem I still see.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Dakota Jack wrote:
The bottom line, Frank, is that the monitor is monitoring another class that is running and reading the upload, viz. UploadOutputStream. I don't know what your setup is, but presumably however you persist the data, this link between the monitor, which is referenced in the output stream wrapper itself is part of the read process, cannot be broken. Right?
Jack
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
