Topic awaiting preservation: Java Thread's Wait For Input etc. (Page 1 of 1)

Alright I have a Java prog that I've set up that can communicate with a Jabber Server (IM). Essentially I'm writing an IM bot. I haven't used a lot of Java but I'm using it on this project a lot so I think this is where I come up to speed.

It's really simple at this point but right now I have a couple of things I want to do and I'm having a hard time figuring out the correct way.

First is I set up a listener to process the IM packets all well and good, however to keep my main thread open I need to put a while( true ) sleep() block in there, what I would prefer to do is set something opposed to sleep so that the thread can wait until the listener is hit. I've tried just putting wait() or thread. wait(); but I can't do that in a static context?

Also similar question. What want to do is spawn a thread that handles certain types of messages. However I want this thread to wait until it has a message instead of an endlessly true loop as well.

Any thoughts?



.:[ Never resist a perfect moment ]:.

Try doing a searh for "java notify threads" or something similar. I would write more on this but I have a plane to catch.

Dan @ Code Town

look if the select function is available in java. That's the way to handle such things in C and basically every unixy language I have run across (windows supports it too).

After another look with some more time I am a bit confused, I think you might have something like:

1. Main Running Thread (public static void main(String[] args))
2. Your Connection Listener thread.

Now, you don't want your main thread to die after you spawn you connection listening thread? I am assuming because your main thread is going to preform some kind of processing on the contents of the listener thread?

If this is not the case then disreguard the rest and clarify your problem.

So, if you are reading this your case is that you want to act on the content from your listening thread.

Most things I have seen at this nature will be discussed on the "server" side of things in a simple client server architecture, as an IMBot is basically an intelligent server of some kind.

I think you will find a section in Thinking in Java (might try 1st edition, I didn't see it in the 3rd) on this, and the adaptation of how to handle multiple requests. You basically have a nice blocking mechanism built into the IO and Socket requests.

So you can say something like:

Vector v = new Vector();
while(true){
Request r = processNewRequest();
v.add(createNewHandlerThread(r));
}

This here would be your entire main class. You basically sit in your main thread and wait for the connections to come in (which is normally a blocking statement ServerSockect's accept method for instance. The above is a little expensive to start new threads, if you want to get a little more efficient you should create a thread pool but that is neither here nor there.

If you are newer to Java you will have to remember that Java takes care of a whole lot more than most other languages. You have built in synchronization, and even some built in blocking. If you were using C for this you might have to program a Semaphore or something to assist in this.

If this didn't help at all, try restating the problem and I will come back and see if I can offer up some more potensially unhelpful advice =)

Dan @ Code Town

The main issue I'm running into is keeping the main thread running while I wait for new connections. It seems like more overhead than I need to do a while(true) loop when really I just want to act when a new packet comes in. (This is based on no technical knowlege just sheer guessing)


I should clarify also (just to make things more complicated ) that this is running for Jabber based IM systems so I'm using a Jabber API library for handling the connection. I've done straight socket listeners before so I think this is what's adding the additional confusion.



.:[ Never resist a perfect moment ]:.

I don't get your problem?

You say 'myServerSocket.accept()' - this blocks until a connection is made.
You do this in a while(true) loop so you can catch the next client that's coming in. You don't waste resources by 'polling'.

This returns you a client socket which in turn blocks on read (set socket timeout), which you pass to another thread.

your main thread (not the one listening with accept - that's a different one) happily runs in your usual event loop and handles your gui.

now, dwelve into the jabber api - I'd expect it to use both accept and read in blocking ways. If not, you can always hack it ;-).

I'm tired - so please forgive me if this does not help you ;-).

So long,

->Tyberius Prime

Ok, so I was close?

What you would normally do is have your soccket.accept() method waiting for connections in the main loop, or at least call the method from the appropriate class in your main loop. When running the socket.accept() (ServerSocket) you will not be cycling, it should be pretty efficient.

If you must spawn a separate thread to handle each individual connection, then I you might need to look into a wait/notify approach for your thread blocking and unblocking.

http://www-106.ibm.com/developerworks/java/library/j-jtp0730.html

Has a good discussion with code, and also points out some pitfalls, like deadlock.

Good luck, hope some of this helps.

Dan @ Code Town

First I'm letting the Jabber API handle the socket connection. So I'm trying not to hack that part of the script. Jabber implements the XMPP protocol on top of the socket connection so there's a lot if handling in there that I don't want to mess with. (Plus I'm pretty sure I shouldn't have to).

Basically I have this code.

// Imports missing for brevity.

public class GameManagerPacketHandler extends Thread implements PacketListener {



	public static String SERVER;

	public static String USER;

	private int Messages = 0;

	

	public XMPPConnection myconn;

	private boolean threadSuspended = false;

	

	public GameManagerPacketHandler( XMPPConnection conn, String server, String user) {

		myconn = conn;

		SERVER = server;

		USER = user;

	}





	

	public synchronized void processPacket( Packet packet ) {

		PacketExtension packetx = packet.getExtension( "x", "techtv.x.prosync" );

		threadSuspended = !threadSuspended;



			// ... Actual Processing deleted for brevity



		}

		

	}

	

	public void run() {

		 while ( true ) {

			try {

				sleep(100);

			} catch (InterruptedException ie) {}

		}

		

	}

}

Which I would like to change to something like an interupt or a wait instread of a while(true) sleep loop.

Gotta run for now, I'll keep browsing through the docs on threads. I'm getting closer I think.

(Next up thread pooling for performance )

-mike



.:[ Never resist a perfect moment ]:.

Hmm I may be going about this wrong it's starting to look like a Thread can't interrupt or pause itself I may need to do some hacking of the API to do this properly. (I pass this class to the XMPP Connection so I'm not calling it myself)



.:[ Never resist a perfect moment ]:.

Alright I think I'm an idiot. I'm trying to make this application as efficient as possible so I was afraid of the sleep command thinking that it would create pauses between calls to the processPacket method.

After some testing it looks like this sleep doesn't cause an immediate response if another thread calls the processPacket method. (I'm trying to confirm this but I tested it with sleep set to 10 secs and got an immediate response so it looks good.



.:[ Never resist a perfect moment ]:.

That is really weird looking. I am guessing that the handling of the class is done in process packet, but I can't for the life of me figure out where you are calling it from. Your thread loop is null, has nothing in it, so I am wondering why you have this setup as a thread. When you call Thread.run() it isn't going to do anything.

What I have to assume from how this class is setup is that you will create this class in a controller class and then that class also calls the processPacket function which means this class doesn't need to be a thread, nor treated like one. If I am missing something please make sure to hit me with a brick. I am pretty tired and me missing stuff isn't uncommon.

Dan @ Code Town