james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: performance figures w/ spool enabled
Date Mon, 28 Oct 2002 19:11:30 GMT
+1

> -----Original Message-----
> From: Steve Short [mailto:sshort@postx.com]
> Sent: 28 October 2002 18:33
> To: James Developers List
> Subject: RE: performance figures w/ spool enabled
> 
> 
> Defer, defer, defer.  There have been a number of issues with file
> repositories in the past 9 months or so, and without a decent set of
> regression tests you risk re-introducing old problems such as the
> ConcurrentModificationException or the 0 size file.  At the moment they
> are stable and working reasonably well - don't touch them - please.
> 
> There is already a todo list item tabled for v3.0 to revisit the
> repostories (mailbox versus spoool queue repositories) and this would be
> a better place for this work.
> 
> Regards
> Steve
> 
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com] 
> > Sent: Monday, October 28, 2002 10:27 AM
> > To: James Developers List
> > Subject: RE: performance figures w/ spool enabled
> > 
> > 
> > I'll give it a shot.  Mind you, one difference is that the 
> > JDBC spool code is able to iterate through the first 1000 
> > entries of the database, whereas each call to 
> > loadPendingMessages() for the file system will have to clone 
> > the entire HashSet again.  But if we can keep that down to 
> > once or twice a minute instead of hundreds of times per 
> > minute, it ought to help.
> > 
> > I'm going to pull the pending messages code into a common 
> > class with an abstract load method.
> > 
> > 	--- Noel
> > 
> > -----Original Message-----
> > From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> > Sent: Monday, October 28, 2002 12:23
> > To: 'James Developers List'
> > Subject: RE: performance figures w/ spool enabled
> > 
> > > Noel J. Bergman wrote:
> > > > Serge wrote:
> > > >   (2) Use the same approach found in JCBCSpoolRepository,
> > > >       where we maintain a small cache of keys.  When the
> > > >       list is exhausted, it is reloaded.  I believe that I
> > > >       can pretty much clone the code from one to the other,
> > > >       with the obvious change in populating the list.
> > > >
> > > > Are either of those approaches something that we want to undertake
> > for
> > > v2.1?
> > > > Do you want to consider this a bug fix, or a performance 
> > enhancement
> > to
> > > > defer?  I don't have a problem implementing the change, 
> > but I don't
> > want
> > > to
> > > > undertake it today if we don't want it until after the release.
> > >
> > > If you can get the code from JDBCSpoolRepository and pretty quickly
> > get
> > > this alternate approach running, then see how your 
> > performance tests 
> > > do... if it's an improvement, I would go ahead and put it 
> > in.  In my 
> > > mind it's known logic, so it's not that big of a deal.
> > 
> > I'm of the same mind as Serge on this one.  If the logic is 
> > already written and has been shown to work, I say put it in.
> > 
> > --Peter
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> > For 
> > additional commands, 
> > e-mail: <mailto:james-dev-help@jakarta.apache.org>
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> > For 
> > additional commands, 
> > e-mail: <mailto:james-dev-help@jakarta.apache.org>
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
<mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message