JamesSpoolManager doesn't shutdown gracefully

• Key: JAMES-9
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Assignee: Unassigned
• Reporter: Serge Knystautas
• Component/s: SpoolManager & Processors
• Fix Version/s: 2.2.0

Environment

Operating System: Other
Platform: Other

Description

On Sat, 29 Sep 2001 06:36, Matthew Pangaro wrote:
> java.lang.IllegalStateException: Using a stale object reference to call a
> disposed Block. at
> org.apache.avalon.phoenix.components.application.BlockInvocationHandler.inv
>oke(BlockInvocationHandler.java:92) at $Proxy9.log(Unknown Source)
> at org.apache.mailet.GenericMailet.log(GenericMailet.java:148)
> at
> org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:3
>71) at java.lang.Thread.run(Thread.java:484)
> I don't know if the same occurs from a timeout of a connection to any of
> the other services. Still shuts down ok, but seems like it should be
> caught, or the object reference should be cleaned up. Sorry if this should
> have been posted to Avalon list, but I wasn't really sure where it
> belonged.

The problem is that transport.JamesSpoolManager does not implement the
dispose method. It should implement dispose() to wait till all currently
executing processors shutdown gracefully. Todo this it will need to make sure
run() shuts down properly.

Comments

[Danny Angus]

James wont shutdown with cntrl-c while there are active connections to SMTP, it
must be killed.

[Danny Angus]

increasing this to High Priority, James still wont shutdown while (at least) a
POP3 connection exists, even if it is inactive.
I suspect this is Avalon related, as connection services are provided by avalon.
Its a Pain, and will be a bigger pain in a high load situation

[Peter M. Goldstein]

The POP3 (and the other protocol services) shutdown problems are not quite the
same as the SpoolManager. Those problems are due to some issues in the
ConnectionManager being used. ConnectionManager changes in my proposal later
today (ran a little bit late with this one) should resolve that issue once and
for all.

The SpoolManager code now implements dispose(), and calls destroy() for each
of the mailets. But it has a more serious problem than can be disastrous.
Specifically, there is a potential race condition in the SpoolManager between
the worker threads that actually process the mail and the action of the dispose
() method, which destroys the mailets. That's bad.

Not sure how critical this issue is, as it only affects systems using mailets
with non-trivial destroy() methods. And it only manifests itself on shutdown
and, even then, only some of the time.

[Noel J. Bergman]

"there is a potential race condition in the SpoolManager between
the worker threads that actually process the mail and the action of the dispose() method, which destroys the mailets"

JamesSpoolManager.dispose() now tells the spooler threads to terminate and then waits (up to 1 minute) for them to complete.