Mike,
I have done some more tests. In case I did not express it
properly in my original post I will give some more background.
The code that fails is runing inside and an RMI based Java
application. Previously my client was a seperate Java application
or a servlet engine that looked up the remote object in the
RMI registry and then executed the methods on the remote
interface. Everythign works fine in this model. The problem
came when I was creating multiple threads inside the RMI
application and those threads were acting like clients to
the RMI application. The lookup works and the method on the
remote interface is called as before. However, in the code
of the interface implementation if there are multiple threads
acting like clients from inside the RMI server then I get the
following errors:
log4j:ERROR Attempted to append to closed appender named
[APPENDER_CONSOLE].
log4j:WARN Not allowed to write to a closed appender.
log4j:ERROR Attempted to append to closed appender named [APPENDER_CMA].
log4j:WARN Not allowed to write to a closed appender.
The initialisation of log4j occurs when the RMI application
starts up. Before any request comes in. All Category instances
are created as:
private static Category cat =
Category.getInstance(ServerStats.class.getName());
private static Category catStats =
Category.getInstance(ServerConf.TAG_LOG_CONF_CATEGORY_STATS);
I am lost. Can anyone suggest anything else.
Thanks,
Aron
Mike Brodhead wrote:
>
> > When that code executes some logging output does not appear in the
> > log files and on the console. However, this only happens if I have
> > multiple callbacks coming quickly one after the other.
>
> Does logging *always* fail when you have multiple threads and *always*
> succeed with a single thread? Or does the behavior vary? It is worth
> running your code several times each way to verify this.
>
> My first guess is that you have some sort of race condition in your
> code that is exercised when you have multiple threads. Debugging
> multithreaded code can be tricky, and things can interact in ways that
> you do not expect.
>
> Think very carefully about what initialization your program must
> perform and what order that initialization must occur in. How can you
> guarantee that the initialization happens in the correct order? How
> can you guarantee that certain initializations only happen once?
>
> Another possibility is that some resource (such has your Log4j
> categories) is being stored in a class variable which is then being
> accessed by multiple threads and thus clobbered by one thread before
> another thread tries to access it.
>
> To some extent, both problems come down to thread safety.
>
> Too bad the problem in this case is with your logging output, as some
> well placed logging statements would be a big help to troubleshoot
> your problem. When I was in the initial statges of getting Log4j to
> work with my app I resorted to the dreaded System.out to good effect.
>
> Hope this helps. Please let us know what you discover.
>
> --mkb
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
