views:

72

answers:

3

I'm chasing a production bug that's intermittent enough to be a real bastich to diagnose properly but frequent enough to be a legitimate nuisance for our customers. While I'm waiting for it to happen again on a machine set to spam the logfile with trace output, I'm trying to come up with a theory on what it could be.

Is there any way for competing file read/writes to create what amounts to a deadlock condition? For instance, let's say I have Thread A that occasionally writes to config.xml, and Thread B that occasionally reads from it. Is there a set of circumstances that would cause Thread B to prevent Thread A from proceeding?

My thanks in advance to anybody who helps with this theoretical fishing expedition.

Edit: To answer Pyrolistical's questions: the code isn't using FileLock, and is running on a WinXP machine. Not asked, but probably worth noting: The production machines are running Java 1.5.

+2  A: 

Temporarily setup your production process to startup with debugging support, add this to how you're starting your java program or to say the tomcat startup:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Then attach to it:

jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8000

And take a look at your stack(s).

JamesG
A: 

FileLock is an inter-process locking mechanism. It does nothing within the same JVM, so that isn't it. I would look at your synchronizations, and specifically at making sure you always acquire multiple locks in the same order.

EJP
A: 

I've gotten some useful tips for chasing the underlying bug, but based on the responses I've gotten, it would seem the correct answer to the actual question is:

No.

Damn. That was anti-climactic.

BlairHippo