Andrew Sancroff

Greenhorn
+ Follow
since Dec 25, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Andrew Sancroff

I should have explained what XMPP-like meant. XMPP uses a single top-level (level-0) <stream> element for the duration of the connection (a separate stream in each direction). Throughout the lifetime of the connection (which can last minutes, hours, days, or years), various level-1 elements are exchanged between the client and server. For example:

My original thinking was to let an XML parser do the job of spotting when a level-1 element was complete so I could then go ahead and process it. But alternatively I could just find the level-1 end tag myself and then feed the level-1 element to the XML parser as a stand-alone document for it to parse for me. Or, since I'm the only user of this protocol (I'm writing both the client and server) and I don't care if it's not pure XML, I can just slap a length in front of each level-1 element so the receiving side can trivially break the stream up into level-1 elements without having to look for end tags. Heck, I could just get rid of the <stream> element entirely since it's really just decorative...the level-1 elements are stand-alone entities and could just as well be promoted to level-0.

I say this is XMPP-like since I'm not actually implementing XMPP. If I were, I'd obviously keep the <stream> element and look for the level-1 end tags myself rather than introducing the "ugly" (but efficient) length field before each level-1 element.

If I've failed to make all of this nonsense clear, just ignore me. I'm satisfied with my hybrid solution, however horrifying it might be to the purist.
This is all in the JDK JavaDoc...

Throws:
IllegalThreadStateException - if the thread group is not empty or if the thread group has already been destroyed.
Update...

Having given this some more thought, I've realized that even if such a parser existed in the JDK, it's wasteful to have a separate parser instance for every client connection. So I'm going to blend new- and old-school "technologies" and put a 16-bit length in front of each XML "stanza". That way a single parser instance can be used.

I know this solution would make an XML purist toss his/her cookies sky-high but sometimes a blend of the old and new works best for a particular application.
"Destroys this thread group and all of its subgroups. This thread group must be empty, indicating that all threads that had been in this thread group have since stopped."
Do you want to be able to tell from outside the application or from within the application? From within the application, take a look at the Thread.enumerate method.

If you want to know from outside the application, I don't know.
Dumb question warning...

Is there a parser included in the SE JDK which is appropriate for parsing an ongoing XML-based "conversation" between a client and server, ala XMPP? I don't want a solution which requires a bunch of threads to be blocked on parse(), waiting for new stanzas to arrive on each connected socket. I'd like a solution which requires only one thread to handle many client connections. When the thread (using NIO) reads data from a socket, it would feed it to the input interface of the associated parser and if the parser has parsed a complete stanza, it fires some events and then returns (whether it fired any events or not) so the thread can go back to waiting for more data on all the sockets.

Is this a reasonable design? Is there a parser in the SE JDK appropriate for this task?

Thanks in advance.
To help you figure out what's going on, add this method to your code and sprinkle calls to it in various places (like in run() and doSomething()). Requires Java 1.5 (for getStackTrace()). Tells you where you are in the code and what thread is executing it.


[ January 02, 2007: Message edited by: Andrew Sancroff ]
[ January 02, 2007: Message edited by: Andrew Sancroff ]
Another note about your example...

Your constructors for b and c take a Thread parameter but call Thread's no-arg constructor (super()), meaning when you call b.start() and c.start() those threads will do nothing and immediately exit. If you want b and c to call a's run() method when you start them, you need to call super(t) in their constructors.
Nicholas, calling a method of a Thread object does not run the method on a different thread. It runs it on the same thread. Your calls to t_2.doSomething() and t_3.doSomething() are executing on the main thread. There is no magic to calling methods of a Thread object. It's just like calling methods of a non-Thread object.

In your example, you have created t_2 and t_3 but you have not started them so their associated threads aren't even running.
Pandora.getBox.open();

There are so many issues to consider. You need to start by reading chapter 14 of The Java Programming Language, 4th edition. Section 14.10 (including all its subsections) is the real mind-blower (the Java memory model).