james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Gerhard" <alan.gerh...@GerCom.Com>
Subject RE: performance figures w/ spool enabled
Date Tue, 29 Oct 2002 02:31:53 GMT
had i steve and steve's eloquence ...

i am sort of in flux with anticipation of the next release and am rather
apprehensive to anything that might delay or damage this, so add this unofficial
+1 for deferral

FWIW
alan



-----Original Message-----
[Stephen McConnell]
I have to agree with Steve on this (i.e. a non-official +1).

I had problems during James depolyment a couple of months ago - part
James, part Cornerstone, - basted on the current status I'm getting
ready to lauch another assault on James deployment.  I know based on the
emails that things are looking good and we are mocving into predicable
behaviour + performace measurement.  This is such a big plus over and
above 2-3 months ago.  I'm really looking forward to playing some more
with the release - and the last thing I want is somethig odd that
doesn;t tie into the results reported ovet the last weeks - not that I
think that there will be anything different - but I will feel better if
is deferred until post release.

Cheers, Steve.


Steve Short wrote:

>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>
>
>
>
>
>

--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
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