Well if its in the session scope it would be removed automatically when the session is invalidated - which happens either when the user logs out or their session times out due to inactivity. (And if you need to do some kind of cleanup you can implement HttpSessionBindingListener to detect when this happens)
If however you put it in the session scope you will need a seperate instance for each user - which means 10 users looking at it will mean 10 beans - and (unless you share the data behind the scenes such as with a static variable) - 10 copies of the data and 10 polls of the server being monitored. That seems to me to be rather inelegant. My opinion (and there are arguments for and against this) is that you should encapsulate both the data and the polling logics in a single bean, and have one instance for each server being monitored, and store this bean in the servlet context rather than the session context . The servlet context is shared between all users and exists for the life of the application. (Note that afaik changes to it arent shared between multiple JVMS in a cluster though). (Dont forget to synchronize the beans methods since its shared between threads!) Now since you know you are storing N number of updates for each server, and I presume that the number of servers being monitored isnt overly vast (ie: thousands), and if you have your beans drop the N+1th element when they do a poll, then you know that you have a pretty constant memory footprint here. (Unless the number of servers or value of N is changed at runtime - but I doubt that would matter too much even then). Since the bean instances are shared between all users and their memory footprint is relatively constant I dont see why it shouldnt be ok to keep it hanging around even when there arent any users. If your really worried about it you could have it keep a counter of the number of users accessing it - when a user logs on and starts monitoring the bean increment the count, and when their session expires you can decrement it. If the count drops to zero trash the bean... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 May 2004 20:35 To: Struts Users Mailing List Subject: RE: scope and presenting realtime data (fwd) Hi, Thanks for your response... as you rightly pointed out the data is 'near realtime' not exactly REAL-TIME. Yes.. we need to store in the servlet context.. but what needs to be the scope.. if scope is request, than we can show only the current value. if the scope is session, than this bean (storing + polling bean) will be maintained even when there is no user is currently watching the data. Is there anyway to *invalidate* this storage bean if nobody has accessed it in some past N minutes? I am new to struts so this question might be be too simple.. thanks & regards -Ramudu On Wed, 26 May 2004, Andrew Hill wrote: > Why not store the info in the servlet context, using different keys for each > server? > > That way if several users are all monitoring the same server they will be > looking at the same set of data. > > Since the data is being multithreaded you will need to make sure you > synchronize in the appropriate places for which purpose you would probably > implement some kind of bean to store this data in an internal collection. > You would probably want to merge the functionality of your polling bean with > this storeage one, so you would be using one bean instance per server, with > all users sharing these beans simultaneously. > > Id suggest that when the bean is asked to pull data for a particular server > it checks to see that a certain period of time has gone by since the last > poll. If not you wouldnt bother pulling another value to add to the set.(Id > suggest at least a second, and more if you have lots of users). If two users > ask for the information within a few milliseconds if each other there is > little point doing an extra poll. By the time the graph is redrawn and hits > the browser even the most current value will be many milliseconds out of > date anyhow and it doesnt make much difference to a human! > > In terms of 'realtime' presentation you probably dont really want to have > the browsers polling the server too much (though it would be easy to do with > a javascript timer that refreshes the page), as all the requests will add > considerably to your server load (especially since the charts need > redrawing). If your setting a minimum polling period as suggested above you > would probably also want to try and somehow cache the resulting chart images > until such time as new data is available, such that several requests coming > in rapidly (probably from different users) could all be serviced with the > same image and cut the need to spend server time re-rendering the chart. > > Thats just my 2 cents worth though so theres probably many better ways of > doing it. > > hth > Andrew > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 26 May 2004 19:42 > To: [EMAIL PROTECTED] > Subject: scope and presenting realtime data (fwd) > > > Hi, > > Can anyone suggest some approach for this issue. > > thanks & regards > -Ramudu > > > ---------- Forwarded message ---------- > Date: Wed, 26 May 2004 14:52:23 +0530 (IST) > From: [EMAIL PROTECTED] > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: scope and presenting realtime data > > Hi, > > We are developing a web based interface (struts + jsp etc) for realtime > monitoring of server cpu usage. > > We have written a bean that will contact the server and get the current > cpu usage and return that value. I want to plot a line graph (using > jfreechart) with the cpu usage in Y-axis and time in X-axis. The Graph > need to plot the last 'N' values + the current value during each refresh. > > The issue is how to remember these last N values. I do not want to assign > session scope for this object as the end-user might monitor for more than > one servers and several users might be using the system at same time. > > How this situation is typically handled in the Struts+jsp environment. > > thanks & regards > -Ramudu > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
