a SwingWorker proxy? could i use ActionListener for this?

every 5-sec. i startx number ofThreads that share aSocket

pool.

in my GUI, i've got aJTable that displays the state theSocket

pool:

(column #1) host name

(column #2) # of sockets connected to that host

(column #3) # of sockets that are being used by the runningThreads

and, the objectServPoolManager that manages theSocket pool is also aThread and basically does this.

(1) discovers new servers

(2) opens "y" number ofSocket connections to each new server.

(3) returns an openSocket to aThread's request for a server connection.

etc. etc.

now, in theJFrame that contains theJTable i start a

SwingWorker.

this worker'sdoInBackground() is an infinite loop that

(1) asks theServPoolManager thread for its status

(2) writes these results toJTable.

(3) loop.

so...

is it "acceptable" for aSwingWorker to run as an infinite loop?

or,

how could i connect there-fresh ofJTable to the action

of a change of state in theSocket pool?

is that possible via anActionListener?

this would be ideal solution though.

as aSwing neophite, an infinite loop indoInBackground()

"seems" like a good idea.

normally i would use a

try{ Thread.sleep(123);}catch(InterruptedException e){}

in thedoInBackground() infinite loop.

but, is that necessary in theSwing world?

sinceSwingWorker is so "lite-weight" and pre-emptable,

may the race condition

of an infinite loop is not bad at all and it

will re-fresh myJTable more...

please help.

[2031 byte] By [dew2hirooa] at [2007-11-27 8:56:06]
# 1
Consider using a java.util.Timer that fires every N milliseconds, and using EventQueue.invokeX() to update the UI.
jvaudrya at 2007-7-12 21:18:24 > top of Java-index,Desktop,Core GUI APIs...
# 2

> Consider using a java.util.Timer that fires every N

> milliseconds, and using EventQueue.invokeX() to

> update the UI.

ok. i will give this a try.

however:

as i read quickly thru "intro to Swing", i think i read that the only

way to simulate multi-thread access to GUI objects in a JFrame is to only

allow SwingWorkers that are started within the relevant JFrame

thread. and all other multi-thread access is undefined.

so, i see that EventQueue is in AWT.

i am going to think of Swing on top of AWT and thus

EventQueue started from within the relevant JFrame is

safe.

dew2hirooa at 2007-7-12 21:18:24 > top of Java-index,Desktop,Core GUI APIs...