Develop Reference

ReentrantReadWriteLock fails to get lock even when its state is Unlocked

I am trying to get lock on a thread using following piece of code:
Lock lock = readLock ? getLock(key).readLock() : getLock(key).writeLock();
try {
boolean locked = lock.tryLock(DEFAULT_TRY_TIME, DEFAULT_TRY_TIME_UNIT); //line 3
// If false, lock is not acquired
if (!locked) {
throw new TryLockTimeoutException(
key + ": Failed to acquire " + lock + " within " + DEFAULT_TRY_TIME_STRING);
}
}
Line 3 returns false after 30 minutes hence TryLockTimeoutException is thrown with error as:
com.concurrent.TryLockTimeoutException: keyIp : Failed to acquire java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock#74be2cee[Unlocked] within 30MINUTES
at com.concurrent.NeAccessLockMap.acquireReadOrWriteLock(NeAccessLockMap.java:72)
Notice that lock state is shown as Unlocked in error.
I am not able to understand why would this happen? Why thread is not able to get lock even when the lock is free.

In your example you try to acquire a write lock, but the read lock is already locked, which prevents you from acquiring the write lock.
Because you can either have one or more read locks acquired, or a single write lock acquired, the write lock is marked as Unlocked when there are read locks acquired.
Try the following code:
ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
new Thread() {
#Override
public void run() {
readWriteLock.readLock().lock();
try {
// block the read lock
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}.start();
if (!readWriteLock.writeLock().tryLock(1, TimeUnit.SECONDS)) {
System.out.println(readWriteLock);
System.out.println(readWriteLock.readLock());
System.out.println(readWriteLock.writeLock());
}
would have output like:
java.util.concurrent.locks.ReentrantReadWriteLock#31221be2[Write locks = 0, Read locks = 1]
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock#377dca04[Read locks = 1]
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock#728938a9[Unlocked]

Java Semaphore Stop Threads

Good afternoon all,
I'm working with Java's semaphore and concurrency for a school project and had a few questions regarding how it works!
If there are no permits available, I need the thread to exit the "queue" - not just sleep until one is ready. Is this possible? As you can see in my try, catch, finally - there is no handle for this event:
try {
semaphore.acquire();
System.out.println(Thread.currentThread().getName() + " aquired for 3 seconds " + semaphore.toString());
Thread.sleep(3000);
}
catch (InterruptedException e) {
e.printStackTrace();
} finally {
semaphore.release();
System.out.println(Thread.currentThread().getName() + " released " + semaphore.toString());
}
Daniel brought up the tryAquire function - this looks great but the tutorials I have read state that semaphores require a try, catch, finally block to prevent a deadlock. My current code (implementing tryAquire) will release in the finally block even if that thread was never acquired. Do you have any suggestions?
public void seatCustomer(int numBurritos) {
try {
if(semaphore.tryAcquire()) {
System.out.println(Thread.currentThread().getName() + " aquired for 3 seconds " + semaphore.toString());
Thread.sleep(3000);
} else {
System.out.println(Thread.currentThread().getName() + " left due to full shop");
}
}
catch (InterruptedException e) {
e.printStackTrace();
} finally {
semaphore.release();
System.out.println(Thread.currentThread().getName() + " released " + semaphore.toString());
}
}

I suggest you read the JavaDocs for Semaphor. In particular, look at the tryAcquire method.
Acquires a permit from this semaphore, only if one is available at the time of invocation.
Acquires a permit, if one is available and returns immediately, with the value true, reducing the number of available permits by one.
If no permit is available then this method will return immediately with the value false.
What this means is you can try to acquire a permit if any are available. If none are available, this method returns false immediately instead of blocking.
You'll have to make your "finally" block a little smarter.
boolean hasPermit = false;
try {
hasPermit = semaphore.tryAcquire();
if (hasPermit) {
// do stuff.
}
} finally {
if (hasPermit) {
semaphore.release();
}
}

Where to use Thread interupt

I have some old code I am working with, and I'm not too experienced with Threads (mostly work on the front end). Anyway, this Thread.sleep is causing the thread to hang and I'm unsure what to do about it. I thought about using a counter and throwing a Thread.currentThread.interupt, but unsure of where to put it or which thread it will interupt. Here is an example of the dump. As you can see the thread count is getting pretty high at 1708.
Any advice?
"Thread-1708" prio=6 tid=0x2ceec400 nid=0x2018 waiting on condition
[0x36cdf000] java.lang.Thread.State: TIMED_WAITING (sleeping) at
java.lang.Thread.sleep(Native Method) Locked ownable synchronizers:
- None "Thread-1707" prio=6 tid=0x2d16b800 nid=0x215c waiting on condition [0x36c8f000] java.lang.Thread.State: TIMED_WAITING
(sleeping) at java.lang.Thread.sleep(Native Method) Locked ownable
synchronizers:
- None
#Override
public void run()
{
Connection con = null;
int i = 0;
while (is_running)
{
try
{
con = ConnectionManager.getConnection();
while (!stack.isEmpty())
{
COUNT++;
String line = (String) stack.pop();
getPartMfr(line);
try
{
if (this.mfr != null && !this.mfr.equals(EMPTY_STR))
{
lookupPart(con, line);
}
}
catch (SQLException e)
{
e.printStackTrace();
}
if (COUNT % 1000 == 0)
{
Log log = LogFactory.getLog(this.getClass());
log.info("Processing Count: " + COUNT);
}
}
}
catch (NamingException e)
{
e.printStackTrace();
}
catch (SQLException e)
{
e.printStackTrace();
}
finally
{
try
{
ConnectionManager.close(con);
}
catch (SQLException e)
{
e.printStackTrace();
}
}
try {
Thread.sleep(80);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
this.finished = true;
}
Here is where it calls the run method, as you can see it does set it to false, but I guess it is missing threads?
HarrisWorker w[] = new HarrisWorker[WORKER_POOL_SIZE];
try
{
for (int i = 0; i < w.length; i++)
{
w[i] = new HarrisWorker(pw);
w[i].start();
}
pw.println(headers());
File inputDir = new File(HARRIS_BASE);
String files[] = inputDir.list();
for (String file : files)
{
try
{
File f = new File(HARRIS_BASE + File.separator + file);
if (f.isDirectory())
continue;
final String workFile = workDir + File.separator + file;
f.renameTo(new File(workFile));
FileReader fr = new FileReader(workFile);
BufferedReader br = new BufferedReader(fr);
String line = br.readLine();
boolean firstLine = true;
while (line != null)
{
if (firstLine)
{
firstLine = false;
line = br.readLine();
continue;
}
if (line.startsWith(","))
{
line = br.readLine();
continue;
}
// if(line.indexOf("103327-1") == -1)
// {
// line = br.readLine();
// continue;
// }
HarrisWorker.stack.push(line);
line = br.readLine();
}
br.close();
fr.close();
for (int i = 0; i < w.length; i++)
{
w[i].is_running = false;
while (!w[i].finished)
{
Thread.sleep(80);
}
}
move2Processed(file, workFile);
long etime = System.currentTimeMillis();
System.out.println("UNIQUE PARTS TOTAL FOUND: " + HarrisWorker.getFoundCount() + " of " + HarrisWorker.getUniqueCount() + ", "
+ (HarrisWorker.getFoundCount() / HarrisWorker.getUniqueCount()));
System.out.println("Time: " + (etime - time));
}
catch (Exception e)
{
e.printStackTrace();
File f = new File(workDir + File.separator + file);
if (f.exists())
{
f.renameTo(new File(HARRIS_BASE + File.separator + ERROR + File.separator + file));
}
}
}
}

As a direct answer to the question in your title - nowhere. There is nowhere in this code that needs a Thread.interrupt().
The fact that the thread name is Thread-1708 does not necessarily mean there are 1708 threads. One can choose arbitrary names for threads. I usually include the name of the executor or service in the thread name. Maybe 1600 are now long stopped and there are only around a hundred alive. Maybe this particular class starts naming at 1700 to distinguish from other uses.
1708 threads may not be a problem. If you have a multi-threaded server that is serving 2000 connections in parallel, then it certainly expectable that there are 2000 threads doing that, along with a bunch of other threads.
You have to understand why the sleep is there and what purpose it serves. It's not there to just hog memory for nothing.
Translating the code to "plaintext" (btw it can be greatly simplified by using try-with-resources to acquire and close the connection):
Acquire a connection
Use the connection to send (I guess) whatever is in the stack
When failed or finished - wait 80ms (THIS is your sleep)
If run flag is still set - repeat from step 1
Finish the thread.
Now reading through this, it's obvious that it's not the sleep that's the problem. It's that the run flag is not set to false. And your thread just continues looping, even if it can't get the connection at all - it will simply spend most of its time waiting for the retry. In fact - even if you completely strip the sleep out (instead of interrupting it mid-way), all you will achieve is that the Threads will start using up more resources. Given that you have both a logger and you print to stdout via printStackTrace, I would say that you have 2 problems:
Something is spawning threads and not stopping them afterwards (not setting their run flag to false when done)
You are likely getting exceptions when getting the Connection, but you never see them in the log.
It might be that the Thread is supposed to set it's own run flag (say when the stack is drained), but you would have to decide that yourself - that depends on a lot of specifics.

Not an answer but some things you should know if you are writing code for a live, production systemn:
:-( Variable and method both have the same name, run. A better name for the variable might be keep_running Or, change the sense of it so that you can write while (! time_to_shut_down) { ... }
:-( Thread.sleep(80) What is this for? It looks like a big red flag to me. You can never fix a concurrency bug by adding a sleep() call to your code. All you can do is make the bug less likely to happen in testing. That means, when the bug finally does bite, it will bite you in the production system.
:-( Your run() method is way too complicated (the keyword try appears four times). Break it up, please.
:-( Ignoring five different exceptions catch (MumbleFoobarException e) { e.printStackTrace(); } Most of those exceptions (but maybe not the InterruptedException) mean that something is wrong. Your program should do something more than just write a message to the standard output.
:-( Writing error messages to standard output. You should be calling log.error(...) so that your application can be configured to send the messages to someplace where somebody might actually see them.

restart a thread after exception is caught

I am reading a UDP feed and I want the thread to attempt to restart if their is a failure. I think I have written my class correctly but would like someone to look over and see if there is something missing or I have written something that won't get the job done. In my catch clause I attempt to restart the thread every 6 seconds for 10 attempts. Is this a good solution, will it work?
class UDPReader extends Thread
{
private Thread t;
private final String ip, socket, queue, threadName;
private String ErrorMessage;
private final JTextArea screen;
UDPReader(String ip, String socket, String queue, String threadName, JTextArea screen) {
this.ip = ip;
this.socket = socket;
this.queue = queue;
this.threadName = threadName;
this.screen = screen;
}
public void run()
{
try {
byte[] i = null;
ipaddrConnection ipaddr = new ipaddrConnection(ip, socket);
parseUDP p = new parseUDP();
screen.append("Thread " + threadName + " running\n");
while(true)
{
i = ipaddr.getPacket();
p.parseUDP(i);
//Thread.sleep(0);
}
}
catch (IOException ex) {
Logger.getLogger(MarketDataReader.class.getName()).log(Level.SEVERE, null, ex);
ErrorMessage = "Thread " + threadName + " has failed, Attempting to Restart";
screen.append("Thread " + threadName + " has failed, Attempting to Restart\n");
Email email = new Email(ErrorMessage,"WARNING Market Data Reader Failure");
for(int i = 0; i < 10 && t.isAlive() == false; i++)
{
try {
start();
Thread.sleep(6000);
} catch (InterruptedException ex1) {
Logger.getLogger(UDPReader.class.getName()).log(Level.SEVERE, null, ex1);
ErrorMessage = "Thread " + threadName + " has failed, Contact System Administraitor";
screen.append("Thread " + threadName + " has failed, Contact System Administraitor\n");
email = new Email(ErrorMessage,"WARNING Market Data Reader Failure");
}
}
}
}
public void start()
{
if (t == null)
{
t = new Thread (this, threadName);
t.start ();
}
}
}

I do not know the logic behind your thread in detail but I would make some suggestions on the design of your code.
It is not clear why inside a class derived from thread you have another thread t.
There is no need to derive from Thread (and I believe it is generally a bad practice). It is common to rather implement Runnable interface and then construct a new thread using it.
.
class UDPReader implements Runnable {
...
}
and then instantiate a thread like this:
Thread t = new Thread(new UDPReader());
As a rule, if a thread fails, it terminates... It does not look good that a failed thread "recreates" itself. The better solution would be to provide a Thread.UncaughtExceptionHandler and in the code that creates your thread analyze failing conditions and restart you thread if needed.
In general, not to mess up, in concurrent programming you have to clearly distinguish the logic of a thread and external logic that manages this thread (its start/interruption/termination). I think, this is what you did not do in your code.

I'd say that it is a very bad design to restart a thread from inside of the same thread.
If you need a 'supervisor' thread then you should most likely create another 'supervisor' thread that would create and start the 'worker' thread whenever it finds out that 'worker' thread is down.

One thing you should be aware of is that when you catch an exception in Java, the program (or thread) does not terminate unless you tell it too.
Therefore, if you caught your exception exactly at the command that caused it to happen - inside the loop - you would not need to run another thread. Your thread is alive and will continue to loop. All you need to do - inside the catch block - is fix things up so that the next loop can continue as usual - close and reopen streams, clear partially filled data structures, stuff like that.
Of course, if further, unrecoverable exceptions happen, you should indeed stop your thread.

Locking a process in Java

I have a Java servlet which calls another software (say S) over a TCP connection. This software S uses a network resource, and the output has to be retrived from a hyperlink(using wget).
Since it's the same hyperlink I need to download my result from (irrespective of the request), it results into incorrect results few requests. I basically need to lock the use of this network resource across different processes (I believe each call from the servlet is going to create a new process).
I tried to use ReentrantLock (but I guess it only works with threads and not accross processes).
Please let me know how can this be achieved.
Thanks

Here is how to do cross-process locking in Java. Adjust to your needs and add error/exception checking/handling as necessary.
// Tester
try {
if (crossProcessLockAcquire(SomeClassInYourApp.class, 3000)) {
// Success - This process now has the lock. (Don't keep it too long.)
}
else {
// Fail (Timeout) - Another process still had the lock after 3 seconds.
}
} finally {
crossProcessLockRelease(); // try/finally is very important.
}
// Acquire - Returns success ( true/false )
private static boolean crossProcessLockAcquire(final Class<?> c, final long waitMS) {
if (fileLock == null && c != null && waitMS > 0) {
try {
long dropDeadTime = System.currentTimeMillis() + waitMS;
File file = new File(lockTempDir, c.getName() + ".lock");
RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
FileChannel fileChannel = randomAccessFile.getChannel();
while (System.currentTimeMillis() < dropDeadTime) {
fileLock = fileChannel.tryLock();
if (fileLock != null) {
break;
}
Thread.sleep(250); // 4 attempts/sec
}
} catch (Exception e) {
e.printStackTrace();
}
}
return fileLock == null ? false : true;
}
// Release
private static void crossProcessLockRelease() {
if (fileLock != null) {
try {
fileLock.release();
fileLock = null;
} catch (IOException e) {
e.printStackTrace();
}
}
}
// Some class vars and a failsafe lock release.
private static File lockTempDir = new File(System.getProperty("java.io.tmpdir") + File.separator + "locks");
private static FileLock fileLock = null;
static {
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run(){
crossProcessLockRelease();
}
});
}

Why are you reusing this TCP connection? If it's easy to set up, just set one up every time you need it. For example, with an HTTP request, you should just make a new request every time.
My guess is that you have something static that shouldn't be, so multiple threads are using it when they should all have their own version.
If they're expensive, consider creating one-per-thread with ThreadLocal.
If even that doesn't work, and you don't mind threads blocking, just add "synchronized" to the method that's causing the problem.

The resource you are trying to lock has to support looking. It would be better if the service didn't need to be locked externally.
As a work around you can use a ServerSocket to lock a resource between processes.