james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Doucette <da...@citilink.com>
Subject Re: Blocked thread in RemoteDelivery
Date Tue, 12 Jun 2001 20:59:45 GMT
>From david@citilink.com
From: David Doucette <david@citilink.com>
Reply-To: david@citilink.com
X-Sender: david@mail.citilink.com
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Sending more detail on the dev listserv...
> For a future version, I'm considering creating a separate thread to send
> each message, and join to that thread for a certain number of seconds, so if
> the message is not sent, it is aborted.  However, this creates extra
> complication in the code, an extra thread created and destroyed for each
> message (or even more complication to build a thread spool), and could cause
> problems for large messages sent over a slow connection.
> Any thoughts on a better way to handle this?  Again, if someone can figure
> out what's hanging it, that's the best of all possible worlds.

I can't really think of a better way to handle it.  If a thread is
hanging, you really do need some other thread to recognize this fact and
deal with it.  Instead of two threads for each configured delivery
thread, I'd recommend one thread that manages all the delivery threads.
This way, rather than joining, each delivery thread could set a flag
periodically (or set a timestamp variable) as it is processing a
message.  The manager could then kill any delivery threads that haven't
set the flag in a period of time (or have a timestamp older than a
period of time).  

As long as the delivery thread does this notification
periodically while processing an email, then even large emails wouldn't
be a problem.  Of course, I don't know the architecture, so maybe the
delivery thread blocks while sending an email.  In this case, it
wouldn't be able to report back periodically and you wouldn't be able to
distinguish between a call that blocks indefinitely and one that just
takes a long time.  Not unless there is a mechanism to programatically
check for activity on a thread.  That would be rather clunky even if it
is possible, however.

> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
> ----- Original Message -----
> From: "scott werden" <scott@scottandrita.com>
> To: <james-user@jakarta.apache.org>
> Sent: Tuesday, June 12, 2001 1:32 AM
> Subject: Blocked thread in RemoteDelivery
> >
> > Outgoing mail stopped being delivered today by my James server and I took
> a
> > look at log files and code to see what was going on. What I discovered is
> > that it appears the one and only delivery thread (created in
> > RemoteDelivery.java) got blocked within RemoteDelivery.deliver(). In the
> > code, a message gets logged (line 109) saying: "attempting delivery of
> XXX",
> > and another at line 130 that should report the message was successfully
> > sent. I never saw the 2nd message in the log file (although I saw the 1st)
> > after James hung, nor was there a message for any exceptions. Seems like
> > something hung in transport.connect() or transport.sendMessage(). I
> > restarted James and all the backed-up messages got sent and it is again
> > working OK. I did up the threads but this is just a delay tactic and not a
> > fix.
> >
> > Anybody got any ideas? Has this bug been fixed? I have release 1.2.1.
> >
> > Thanks,
> > Scott W.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-user-help@jakarta.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org

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

View raw message