james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Inactivity
Date Mon, 29 Jul 2002 14:11:17 GMT

Labib,

I did review your suggested patches although I didn't post a reply to
the lists.  The raise header code looks mostly ok, with a couple of
caveats.

i) I don't think there should be a hardcoded 2 sec delay for the bounce
window.

ii) I don't understand why the raiseHeader method is returning "1" when
it is passed a null.  To me this looks like an exceptional condition.  I
would expect the method to throw an exception to indicate that something
unexpected happened.

iii) There is no javadoc provided for the new methods in NotifySender
and NotifyPostmaster contrary to Jakarta code standards.

I'm less crazy about the sleeps, not because I think they'll have a
disastrous effect on performance, but rather because they seem like the
wrong solution to the stated problem.  Basically I have no idea what
makes these particular exceptions merit sleep calls, while others
throughout the system do not.  Yes, they're in loops, but that's hardly
unusual.  

>From your email:

"2. I added a sleep in the catch block in the main loop of
RemoteDelivery.java (I indeed got a endless loop here producing 40MB of
logs after startup till I was able to stop James again. How? I forgot to
add the dbSPOOL repository type to the mailstore blocks configuration.
Which led to a NullPointerException in the loop since the exception in
the initphase is being catched.)"

It seems like the way to solve this is by handling the
NullPointerException in the initphase - not by adding a sleep to the run
that makes it easier to kill the system once it's running and throwing
errors.

And again, on the general principle that hard coded timeouts are bad, if
we're going to put in these sleep calls I don't see why they'd be
hardcoded to a fixed 2 sec.

So my comments are +1 on the raise header stuff once the above caveats
are addressed, -1 on the sleeps.

--Peter

> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Monday, July 29, 2002 4:46 AM
> To: James Developers List
> Subject: RE: Inactivity
> 
> Marcus,
> 
> I believe your patches were in the wrong format, and to be honest I'd
have
> to understand what implications your addition of a sleep call would
have
> on
> perfomance before I added that.
> 
> If you want to re-send diff -u output for the traps you made for loops
> I'll
> gladly review and commit them.
> If you also want to explain how sleep is not going to affect
performance
> under high load I'll review that too, but seperatly.
> 
> Appologies again for sticking myself with an unmanageable back log.
> 
> d.
> 
> > -----Original Message-----
> > From: Labib Iskander, Marcus [mailto:ml@cm4all.com]
> > Sent: 29 July 2002 09:32
> > To: 'James Developers List'
> > Subject: RE: Inactivity
> >
> >
> > I posted some minor changes some time ago and nobody did actually
> > answer in
> > any way.
> > In fact I would have prefered beeing told it is all crap, but I
think it
> > isn't: I am using JAMES with my patches applied (in production).
> >
> > Marcus
> >
> > > -----Original Message-----
> > > From: Danny Angus [mailto:danny@apache.org]
> > > Sent: Saturday, July 27, 2002 9:58 AM
> > > To: James Developer List
> > > Subject: Inactivity
> > >
> > >
> > > Everyone,
> > >
> > > Just a few words regarding inactivity.
> > >
> > > If no-one is participating on the users list, or the dev list, if
the
> > > commiters are commited elsewhere, and happy that James is
> > > good enough for
> > > their own uses then the project will be quiet.
> > >
> > > Apache projects move forward because people tend to get fed
> > > up asking for
> > > fixes, and submit them themselves.
> > >
> > > If you want to start contributing to James, to revitalise the
> > > project, then
> > > do just that contribute. We have a TODO in xdocs todo.xml,
> > > and there's 14
> > > open bugs in bugzilla, and the documentation needs work.
> > > Alternatively make
> > > something new and offer it up. We're always happy to receive
> > > contributions
> > > of any kind.
> > >
> > > d.
> > >
> > >
> > >
> > >
> > >
> > > --
> > > 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