bitcoin-qt stops subsequent RPC calls, then won't shut down I am running latest bitcoin client,  0.9.2.1 - running on 64bit ubuntu..

I can start up the bitcoin client, via bitcoin-qt -server or bitcoind -daemon (both have the same behaviors)....
... once the client is running, my Railo app is making the RPC JSON calls.. The first couple work perfectly, but from that point on, the http calls will simply time out.

then I restart the client, well, try to.. upon restarting it, it tells me "cannot obtain a lock on data directory..  bitcoin core is probably already running".

so at this point, it's impossible to gracefully stop the client (I have tried waiting overnight for it to stop, and no go).   If i restart the computer, start the bitcoin client again, I will be able to process a couple commands and then it'll start timing out again.

2014-09-08 17:20:22 AddLocal(73.my.ip.addy:8333,4)
2014-09-08 17:20:22 ext-ip thread exit
2014-09-08 17:20:23 146 addresses found from DNS seeds
2014-09-08 17:20:23 dnsseed thread exit
2014-09-08 17:20:27 receive version message: /Satoshi:0.9.2.1/: version 70002, blocks=319733, us=73.my.ip.addy:50804, them=74.someone.else.240:8333, peer=74.someone.else.240:8333
2014-09-08 17:20:27 Added time data, samples 2, offset -1 (+0 minutes)
2014-09-08 17:20:27 receive version message: /Satoshi:0.9.1/: version 70002, blocks=319733, us=73.my.ip.addy:49165, them=74.someone.else.180:8333, peer=74.someone.else.180:8333
2014-09-08 17:20:27 Added time data, samples 3, offset -1 (+0 minutes)
2014-09-08 17:20:39 receive version message: /Satoshi:0.9.2.1/: version 70002, blocks=319733, us=73.my.ip.addy:54101, them=37.someone.else.27:8333, peer=37.someone.else.27:8333
2014-09-08 17:20:39 Added time data, samples 4, offset -1 (+0 minutes)
2014-09-08 17:20:43 UpdateTip: new best=0000000000000000092cd65c42a96763e0028edd607555  height=319734  log2_work=80.577054  tx=46257023  date=2014-09-08 17:20:32 progress=1.000000
2014-09-08 17:20:43 ProcessBlock: ACCEPTED
2014-09-08 17:20:45 receive version message: /Satoshi:0.9.1/: version 70002, blocks=319734, us=73.my.ip.addy:50345, them=61.someone.else.11:8333, peer=61.someone.else.11:8333
2014-09-08 17:20:45 Added time data, samples 5, offset +0 (+0 minutes)
2014-09-08 17:20:45 nTimeOffset = -1  (+0 minutes)
2014-09-08 17:21:08 receive version message: /mining.bitcoinaffiliatenetwork.com:0.9.2.1/: version 70002, blocks=319734, us=73.my.ip.addy:52554, them=74.soemone.else.12:8333, peer=74.soemone.else.12:8333
2014-09-08 17:21:08 Added time data, samples 6, offset -1 (+0 minutes)
2014-09-08 17:21:08 connect() to 173.soemone.else.82:8333 failed after select(): Connection refused (111)
2014-09-08 17:21:20 receive version message: /Satoshi:0.9.1/: version 70002, blocks=319734, us=73.my.ip.addy:35721, them=46.someone.else.134:8333, peer=46.someone.else.134:8333
2014-09-08 17:21:20 Added time data, samples 7, offset +0 (+0 minutes)
2014-09-08 17:21:20 nTimeOffset = -1  (+0 minutes)


at this point, i do my rpc calls again, and it starts to time out..  so I figure i'll restart the bitcoin client.. 

username@computer:~$ bitcoind -stop
: Cannot obtain a lock on data directory /home/username/.bitcoin. Bitcoin Core is probably already running.


after I type the above, the log file then shows:
2014-09-08 17:30:17 : Cannot obtain a lock on data directory /home/mrtom/.bitcoin. Bitcoin Core is probably already running.

2014-09-08 17:30:17 Shutdown : In progress...
2014-09-08 17:30:17 StopNode()
2014-09-08 17:30:17 Shutdown : done


Even after reading through the whole log, there are no strong error messages..

Maybe i'm hitting a connection limit or something really fast?
I was having a different somewhat related problem and stumbled across this thread. It seems that bitcoin-qt creates a .lock file to make sure no other program is using the same folder. If the app crashes, the lock file might not be deleted which could cause it to throw up an error about the program already being open. The .lock file is hidden, though, so you won't see it unless you have hidden files turned on. Deleting the .lock file might fix this for you.