gator: Use Java 1.5+ Executor for Server Log Event Handling

[GoogleCodeExporter]

Currently the SocketServer uses explicit thread management for handling
client logging event messages.  The use of java.util.concurrent.Executor
would provide two significant benefits:
 - Improved resource usage/performance
 - Better resource management (e.g. stopping all client threads on shutdown)

Original issue reported on code.google.com by marvin.addison@gmail.com on 26 Apr 2010 at 5:30

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 26 Apr 2010 at 5:30

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 26 Apr 2010 at 5:30

• Changed state: Started

[GoogleCodeExporter]

Work on this issue revealed a potentially severe deadlock case in
LoggingEventHandler.  Apparently the constructor to ObjectInputStream blocks 
until it
has read the object input stream header from the underlying input stream:

    public ObjectInputStream(InputStream in) throws IOException {
    verifySubclass();
    bin = new BlockDataInputStream(in);
    handles = new HandleTable(10);
    vlist = new ValidationList();
    enableOverride = false;
    readStreamHeader();  // This can block if stream is empty
    bin.setBlockDataMode(true);
    }

If for some reason the socket does not contain any data at that point, the 
server
socket polling thread would block indefinitely.

The logic has been changed such that initializing a new LoggingEventHandler 
instance
does not allocate a new ObjectInputStream.  That logic has been moved to the 
run()
method, which executes on a separate thread and can safely block on IO 
operations.

Original comment by marvin.addison@gmail.com on 27 Apr 2010 at 2:33

[GoogleCodeExporter]

Fixed in r1285.

Original comment by marvin.addison@gmail.com on 27 Apr 2010 at 7:01

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 27 Apr 2010 at 7:02

• Changed state: Fixed