Why notify/notifyAll method doesn't resume the waiting thread quickly?
I am currently working on a socket based IM server, I get messages from multiple clients simultaneously and put them into queues, for each queue in my server I have a separate listener running in a thread, as soon as a packet comes in the queue (from any client) itˇs related thread is notified to get that packet from thread and process it.
Here I am using wait/notify blocking mechanism to control loop in my listener thread. My logic works like this
1)When Listener thread starts it calls the synchronized getNextPacket method on that queue if the queue has any packet (i.e. itˇs length is greater then zero) then it will remove that packet from the underlying vector (NOTE: I am using Vector to contain packets) and return that packet to listener thread, else if queue doesnˇt have any packet (i.e. its size is zero) then I will call wait() method which causes the listener thread to wait.
2)Now when any client adds some packet in that queue using synchronized addPacket( ) method I first add that packet in the underlying vector and then call notify()/notifyAll() to awake that listener thread, which again calls the getNextPacket() method and this cycle continuous like this.
So multiple threads (clients) are adding data in the queue using synchronized method, only one listener thread is getting data from that queue using a synchronized method again 兒 .
This approach works fine but sometimes I have noticed that the listener thread doesnˇt resume just after notiy() / notifyAll() has been called , sometimes it resumes after a long time sometimes it even donˇt resume (after waiting a long time I assumed this).
Solutions I tried
1)I did set the listener Threadˇs priority to Maximum but facing same problem again.
For better understanding I am also sending you the code for my queue class and itˇs listener thread.
CODE OF QUEUE CLASS
import java.util.Vector;
import org.apache.log4j.Logger;
import com.tcm.unicorn.server.UnicornCustomeObject;
/**
* @author sajjad.paracha
*
*/
publicclass UIMPCommandsQueue{
privatestaticfinal Logger logger=Logger.getLogger(UIMPCommandsQueue.class);
/**
* Contains all the packets from clients
*/
private Vector <UnicornCustomeObject> unicornCustomeObjectQueue =new Vector<UnicornCustomeObject>();
private UIMPCommandsQueue(){
}
privatestatic UIMPCommandsQueue uIMPCommandsQueue =null;
publicstatic UIMPCommandsQueue getInstance(){
synchronized(UIMPCommandsQueue.class){
if(uIMPCommandsQueue!=null){
return uIMPCommandsQueue;
}else
return uIMPCommandsQueue =new UIMPCommandsQueue();
}
}
/**
* Adds a new command
* @param unicornCustomeObject
*/
publicsynchronizedvoid addCommandPakcet(UnicornCustomeObject unicornCustomeObject){
logger.debug("[[[[[[[[[[[[[[[[[[[[[[[[[[Going to add a packet in queue no "+unicornCustomeObject.getClientSession().getRequestQueueNo());
unicornCustomeObjectQueue.add(unicornCustomeObject);
//** Notify the Listener (RequestProcessor) Thread that a new packet has been arrived in the queue
//** So it now can again start it's processing
notifyAll();
}
/**
* Removes an object from queue whose processing has been started or completed
* @param unicornCustomeObject
* @return
*/
privateboolean removeCommandPacket(UnicornCustomeObject unicornCustomeObject){
return unicornCustomeObjectQueue.remove(unicornCustomeObject);
}
/**
*
If no packet is available in queue it retuns null value
*otherwise returns an object from that queue
*
* @return unicornCustomeObject
*/
publicsynchronized UnicornCustomeObject getNextCommandPacket(){
if(unicornCustomeObjectQueue.size()>0){
UnicornCustomeObject unicornCustomeObject = unicornCustomeObjectQueue.get(0);
logger.debug("[[[[[[[[[[[[[[[[[[[[[[[[[[Got a packet from queue no "+unicornCustomeObject.getClientSession().getRequestQueueNo());
logger.debug("[[[[[[[[[[[[[[[[[[[[[[[[[[Going to remove a packet from queue no "+unicornCustomeObject.getClientSession().getRequestQueueNo());
removeCommandPacket(unicornCustomeObject);
return unicornCustomeObject;
}else{
try{
//** Force the Listener (RequestProcessor) Thread to wait for notification
//** This Thread will be only notified if a new command packet has been arrived(added) in the
//** Queue i.e in addCommandPacket Method
wait();
}catch (InterruptedException e){
logger.error("",e);
}
returnnull;
}
}
}
CODE OF LISTENER CLASS
import org.apache.log4j.Logger;
import com.tcm.unicorn.server.UnicornCustomeObject;
publicclass RequestProcessorimplements Runnable{
/**
* will listen on Request queue for any new massages
*/
publicvoid run(){
//** get an instance of RequestQueue before the loop
UIMPCommandsQueue requestQueue= UIMPCommandsQueue.getInstance();
while(true){
try{
//**call the blocking method getNextCommandPacket()
UnicornCustomeObject unicornCustomeObject= requestQueue.getNextCommandPacket();
if(unicornCustomeObject!=null){
System.out.println("Got a pcket will process it now.......");
}
}catch(Exception exp){
exp.printStackTrace();
}
}
}
}
Can anybody please tell me where I am doing something wrong and whats the best way to get rid of this situation .
Thanks in advance
Message was edited by:
meetsaju
[8976 byte] By [
meetsajua] at [2007-11-27 1:54:34]
# 1
This would normally be written as
while (queue.isEmpty())
{
wait();
}
return queue.remove(0);
But have you looked into the various implementations of BlockingQueue, which do all this stuff for you?
ejpa at 2007-7-12 1:26:25 >
# 2
Thanks for your tip i a now using LinkedBlockingQueue and the frequency of that problem has been remarkably reduced .... still one tester (QA person) of my application has reported that in last 6-7 hours he faced that same problem only one time....
I am after that problem but believe that using LinkedBlockingQueue i will be able to get rid of it ....
will update you on this issue
# 3
Still the same problem :(.....
I now have checked it for one writer and ofcourse one reader thread
now my senario is
One RequestProcessor listening on the queue and only one other thread putting data in queue
but still a time appears that when after adding a packet the queue, listener is notified , listener cant resume himself and so the apllication kind of hangs.
Have been in this problem since a weak now ...... plzzzzzzzzz it would be a nice favour if you help me get rid of this situation.......
# 4
I'd like to see your current code. Are you sure the reader isn't blocked doing something else? I have two threads that have been doing this continuously since about 1997 and they've never had this problem.
ejpa at 2007-7-12 1:26:25 >
# 5
Here is what i want to do ..... i have put all client /queue processing logic under one class and it's2 inner classes(Request Processor/Client)......
This is a very rare case (When request processor theard goes in BLOCKED state) and yes i have seen my RequestProcessor Thread going in BLOCKED state .
After adding a new packet i always check if request processor thread isin Blocked state to get rid of this issue i try to call Thread.yield() this has solved my problem but still cannt understand why my request processor thread goes in Blocked state.
I have created a simulator for the same issue you see the code below also can run it as a standalone class (ofcourse not without log4j :) )
/**
*
*/
package com.tcm.unicorn.server.test;
import java.lang.Thread.State;
import java.util.concurrent.LinkedBlockingQueue;
import org.apache.log4j.Logger;
/**
* @author sajjad.paracha
*
*/
public class UIMPRequestCommandsQueue {
private static final Logger logger=Logger.getLogger(UIMPRequestCommandsQueue.class);
/**
* Contains all the packets from clients
*
* */
private LinkedBlockingQueue<String> unicornCustomeObjectQueue = new LinkedBlockingQueue<String>();
Thread requestProcessorThread;
Thread clientThread[] = new Thread[15];
public UIMPRequestCommandsQueue(){
RequestProcessor requestProcessor= new RequestProcessor();
requestProcessorThread = new Thread(requestProcessor);
requestProcessorThread.setName("Request processor for queue ");
requestProcessorThread.start();
for(int i=0;i<clientThread.length;i++){
clientThread[i]=new Thread(new Client(i*10));
clientThread[i].start();
}
}
int counter = 0;
public void addCommandPakcet(String packet){
try {
counter++;
unicornCustomeObjectQueue.put(packet);
if(requestProcessorThread.getState().equals(State.BLOCKED)){
logger.info(">>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state");
Thread.yield();
}
} catch (InterruptedException e) {
logger.debug("",e);
}
}
/**
* @param args
*/
public static void main(String[] args) {
UIMPRequestCommandsQueue uIMPRequestCommandsQueue = new UIMPRequestCommandsQueue();
}
public class RequestProcessor implements Runnable {
/**
* Process the command from a client
* @param commandFromClient
* @return list of possile response commands from server
* @throws InterruptedException
*/
private void processCommandFromClient(String packet) throws InterruptedException {
logger.info("[[[[[[[[[[[[[[[[[[[[[[[process the packet no "+packet);
Thread.sleep(500);
}
/**
* will listen on Request queue for any new massages
*/
public void run() {
while(true){
try{
String packet = unicornCustomeObjectQueue.take();
//logger.info("<<<<<<<<<<<<<<<<<<<<<<<< Got Packet no "+counter+" From Queue >>>>>>>>>>>>>>>>>>>>>>>>>>>");
processCommandFromClient(packet);
}catch (InterruptedException e) {
logger.debug("",e);
}catch(Exception exp){
logger.error("",exp);
}
}
}
}
public class Client implements Runnable{
int loopIndex =0;
public Client(int loopIndex){
this.loopIndex = loopIndex;
}
public void run() {
for(int i=loopIndex;i<loopIndex+10;i++){
addCommandPakcet(""+i);
}
}
}
}
>
# 6
> solved my problem but still cannt understand why my
> request processor thread goes in Blocked state.
Because it hasn't executed yet, because the current thread is still running. Java threads aren't pre-emptive and you're probably not running on a real-time operating system. If you want to be sure that the request has been taken straight after the put(), call Thread.yield(), and/or give the RequestProcessorThread a higher priority.
ejpa at 2007-7-12 1:26:26 >
# 7
Just need a suggestion !
Is it a good idea to add packets from different clients (from inputstreams of their sockets) and add them all to a queue (obviously in my server application i am using more then one queues like that but lets for the sake of simplicity we consider having one queue in our application)..... Which means to a single queue their would be multiple Writer Threads and single reader Thread (Request processor) .
OR is there any other good way to do that.
Well just to remind you I am working on an IM (Instant messaging) Server .I have to manage different messages coming from different clients for this purpose I use a queue to store all those messages and then process them one by one. Here is a simple diagrame of this case
-
Request Processor Thread
-
|
|
|
|
|Take Packet 4m queue
|
|
Queue
--
||||||||||
--
|
|
|
|Put Packets in queue
|
|
|
|
Client1 Client2Client3 Client4 Client5Client6厖?br>
Another way could be to manage one queue for each client which obviously is not a good idea. This is the best solution in my mind rite now if you have any other good idea then please tell me .
Thanks in advance
# 8
Another question !
in my previous programe i have seen a starange behavior , my processor thread sometimes processes the later message before the message came before that in queue here is an output of my debug statements
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 10
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 11
INFO :03 May 2007 11:21:17,>>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state
INFO :03 May 2007 11:21:17,>>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state
INFO :03 May 2007 11:21:17,>>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state
INFO :03 May 2007 11:21:17,>>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 30
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 13
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 0
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 12
INFO :03 May 2007 11:21:17,>>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 20
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 40
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 31
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 14
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 15
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 32
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 33
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 16
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 34
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 17
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 35
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 18
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 36
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 19
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 37
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 41
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 38
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 39
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 42
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 43
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 21
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 44
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 22
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 45
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 23
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 46
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 24
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 47
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 25
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 26
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 49
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 48
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 27
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 28
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 1
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 2
look at the lines
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 49
INFO :03 May 2007 11:21:17,[[[[[[[[[[[[[[[[[[[[[[[process the packet no 48
as for as i know it shouldnt be the case as we are using a FIFO queue here....just querious how it is possible that a later message is taken from a FIFO queue.
# 9
You're probably not numbering the packets correctly. Somewhere up there you have counter++ without any synchronization.
ejpa at 2007-7-12 1:26:26 >
# 10
private void processCommandFromClient(String packet) throws InterruptedException {
logger.info("[[[[[[[[[[[[[[[[[[[[[[[process the packet no "+packet);
Thread.sleep(500);
}
If you see the above code i am no more using the counter as packet code, i just print the packet itself .Note here packet will also contain any value from 0,1,2,3,4,..........so the process method will always print the no of packet being processed currently ......
# 11
I m also thinking to make following statement
unicornCustomeObjectQueue.put(packet);
as
synchronized (){
unicornCustomeObjectQueue.put(packet);
}
so that only one client thread can enter a packet in the queue at one time,i have seen that put method(of LinkedBlockingQueue) is not synchronized y is so ?shouldnt it be in synchronized way?
# 12
I thought everything in java.util.concurrent was thread-safe but without using synchronization, that's its whole point.I'd need to see how your packets get numbered to comment on the other issue.
ejpa at 2007-7-12 1:26:26 >
# 13
In following sub class named Client i am creating packets for each client , so each client will Create 10 packets and addthem to the queue
public class Client implements Runnable{
int loopIndex =0;
public Client(int loopIndex){
this.loopIndex = loopIndex;
}
public void run() {
for(int i=loopIndex;i<loopIndex+10;i++){
addCommandPakcet(""+i);
}
}
}
For clear understanding i am sending you the code of my test class with few modifications
/**
*
*/
package com.tcm.unicorn.server.test;
import java.lang.Thread.State;
import java.util.concurrent.LinkedBlockingQueue;
import org.apache.log4j.Logger;
/**
* @author sajjad.paracha
*
*/
public class UIMPRequestCommandsQueue {
private static final Logger logger=Logger.getLogger(UIMPRequestCommandsQueue.class);
/**
* Contains all the packets from clients
*
* */
private LinkedBlockingQueue><String> unicornCustomeObjectQueue = new LinkedBlockingQueue<String>();
Thread clientThread[] = new Thread[5];
Thread requestProcessorThread[]=new Thread[1] ;
public UIMPRequestCommandsQueue(){
for(int i=0;i<requestProcessorThread.length;i++){
RequestProcessor requestProcessor= new RequestProcessor();
requestProcessorThread[i] = new Thread(requestProcessor);
requestProcessorThread[i].setPriority(Thread.MAX_PRIORITY);
requestProcessorThread[i].setName("Request processor for queue ");
requestProcessorThread[i].start();
}
for(int i=0;i<clientThread.length;i++){
clientThread[i]=new Thread(new Client(i*10));
clientThread[i].start();
}
}
public void addCommandPakcet(String packet){
try {
unicornCustomeObjectQueue.put(packet);
for(int i=0;i<requestProcessorThread.length;i++){
if(requestProcessorThread[i].getState().equals(State.BLOCKED)){
logger.info(">>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state");
Thread.yield();
}
}
} catch (InterruptedException e) {
logger.debug("",e);
}
}
/**
* @param args
*/
public static void main(String[] args) {
UIMPRequestCommandsQueue uIMPRequestCommandsQueue = new UIMPRequestCommandsQueue();
}
public class RequestProcessor implements Runnable {
/**
* Process the command from a client
* @param commandFromClient
* @return list of possile response commands from server
* @throws InterruptedException
*/
private void processCommandFromClient(String packet) throws InterruptedException {
logger.info("[[[[[[[[[[[[[[[[[[[[[[[process the packet no "+packet);
Thread.sleep(10);
}
/**
* will listen on Request queue for any new massages
*/
public void run() {
while(true){
try{
String packet = unicornCustomeObjectQueue.take();
//logger.info("<<<<<<<<<<<<<<<<<<<<<<<< Got Packet no "+counter+" From Queue >>>>>>>>>>>>>>>>>>>>>>>>>>>");
processCommandFromClient(packet);
}catch (InterruptedException e) {
logger.debug("",e);
}catch(Exception exp){
logger.error("",exp);
}
}
}
}
public class Client implements Runnable{
int loopIndex =0;
public Client(int loopIndex){
this.loopIndex = loopIndex;
}
public void run() {
for(int i=loopIndex;i<loopIndex+10;i++){
addCommandPakcet(""+i);
}
}
}
}
>
# 14
I see, well you might just be looking at a vagary of thread scheduling. I can't see how the packets can possibly get removed in the wrong order but I can see a thread taking a packet and then yielding to another thread which takes the next packet and logs it, then the first thread runs and logs its packet, so the *log* is out of order ...
ejpa at 2007-7-12 1:26:26 >
# 15
> I see, well you might just be looking at a vagary of
> thread scheduling.
Sorry I didnt get your above point, is there something wrong with thread scheduling?
> I can't see how the packets can
> possibly get removed in the wrong order but I can see
> a thread taking a packet and then yielding to another
> thread which takes the next packet and logs it, then
> the first thread runs and logs its packet, so the
> *log* is out of order ...
Yeah thats true, actually it isnt the queue problem it is basically the thread which is processing a packet before the later packet.
Now need another advice
As far as i understood this problem of thread going in Block state comes when their are many threads writing into the queue ,their may be a possibility that monitor (for which Request Processor thread is waiting and has gone in BLOCK state) is distributed between those writer threads for a long long time and the request processor thread waits for that long long time to get that monitor (as those threads are many in no so their possibility of getting monitor is much more then the Request processor thread).
if above is rite then i have following suggestions to get rid of this problem
1) We may increase the no of request processor Threads , 4-5 request processor Threads for a queue. But this once again cant guarantee that these threads (request processor Threads) wont go in BLOCK state (all of them).
2) If I make the addCommandPacket() method synchronized then only one Writer thread will be able to add the packet in that queue at a time, and also I will be checking request Processor Thread ,if request processor thread is in Block state I will yield the current thread , so that request processor will have a chance to get that monitor and will process that packet. Since all this is done in synchronized method so all the other writer threads will have to wait (no one of them will be requesting for the monitor of that queue ) and so the problem we are facing wont happen again .
Is it possible and will it happen like this or I m missing something here?
addCommandPakcet will now look like this
public synchronized void addCommandPakcet(String packet){
try {
unicornCustomeObjectQueue.put(packet);
for(int i=0;i<requestProcessorThread.length;i++){
if(requestProcessorThread[i].getState().equals(State.BLOCKED)){
logger.info(">>>>>>>>>>>>>>>>>>>>>>>>requestProcessorThread is in block state");
Thread.yield();
}
}
} catch (InterruptedException e) {
logger.debug("",e);
}
}
# 16
I don't understand 'the problem we are facing'.If one particular thread gets blocked for a long time while other threads are busily processing the queue, who cares? Who cares about 'fairness' among these threads as long as the work gets done?
ejpa at 2007-7-21 20:15:48 >
# 17
> I don't understand 'the problem we are facing'.
>
> If one particular thread gets blocked for a long time
> while other threads are busily processing the queue,
> who cares? Who cares about 'fairness' among these
> threads as long as the work gets done?
If I understood you correctly you are basicaly with my following idea
1)We may increase the no of request processor Threads , 4-5 request processor Threads for a queue. But this once again cant guarantee that these threads (request processor Threads) wont go in BLOCK state (all of them).
Actually I proposed 2 different solutions in my last reply , I was asking that should we go with above suggestion or the other one as following
2)If I make the addCommandPacket() method synchronized then only one Writer thread will be able to add the packet in that queue at a time, and also I will be checking request Processor Thread ,if request processor thread is in Block state I will yield the current thread , so that request processor will have a chance to get that monitor and will process that packet. Since all this is done in synchronized method so all the other writer threads will have to wait (no one of them will be requesting for the monitor of that queue ) and so the problem we are facing wont happen again .
Remember that only the RequestProcessorThread(s) (Thread who are reading from queue and then processing packets) go in BLOCK state while The Threads writing packets to the queue are still writing those packets.
Using my first suggestion I can get rid of that problem , but I think if we use the 2nd one it will just slow the server since all the other client threads will be waiting for single client to get out of that synchronized addCommandPacket() method.
Sorry for inconvenience , but I was just asking for your kind suggestion about those 2 suggestions.
Thanks for your continuous interest in this thread I really appreciate that .And desperately waiting for your suggestion.
# 18
If all the threads are getting into the BLOCKED state there is something wrong with your concurrent access and locking. But if you're using a java.util.concurrent.BlockingQueue implementation that shouldn't be happening. This is well-designed and very well-tested code.
So what I don't understand is whether you're talking about a genuine problem you've actually seen, which I would find hard to believe if you're leaving all the locking up to the java.util.concurrent code, or is this just something you think might happen? - in which case stop worrying (and learn to love the bomb).
ejpa at 2007-7-21 20:15:48 >
