SwingWorker.execute() silently fails?

[Ben Phillips]

REPOST: I don't know why but the first attempt to post this apparently
silently failed.

I've got a strange app hang. A particular button click pops up a modal
"Please Wait" dialog, then constructs a SwingWorker implementation and
calls execute() on it. The done() method removes the dialog.

Nothing happens as a result of execute(), and as a result the dialog
never goes away and the app is hung.

This is a really strange one, because nothing in the API docs or
tutorial gives any hint as to what the problem could be.

My done() method calls get(), so I thought it could be hanging there
(though it really shouldn't, since done() shouldn't be called until
it's, well, done).

But I put a debugging System.out.println() in doInBackground() and it
never printed its message.

The worker being executed is definitely of the same class as contains my
overridden doInBackground() and done() methods.

doInBackground() has the println as its first thing.

done() hides that dialog before calling get() so even if somehow only
done() was getting called, and get() hanging as a result, the modal
dialog should have disappeared. It didn't.

In short, neither doInBackground() nor done() is being called.

Both of my implementations have @Override tags and there are no compiler
errors, so it's not the case that I'm accidentally failing to override
and it's actually running do-nothing superclass implementations of those
methods.

The SwingWorker subclass instance is a fresh one. The code is FooWorker
worker = new FooWorker(argument); worker.execute();

Put simply, SwingWorker.execute() appears to be doing nothing.

What could the problem be?

The javadocs for execute() say:

Schedules this SwingWorker for execution on a worker thread. There
are a number of worker threads available. In the event all worker
threads are busy handling other SwingWorkers this SwingWorker is
placed in a waiting queue.

It seems to be a bug is the sole SwingWorker can get put on a waiting
queue and never run. Or is an app that uses SwingWorker supposed to do
something to set the size of the thread pool larger than zero before any
of this stuff will work correctly?

On a side note, JFrame.setLocationRelativeTo(null) is supposed to center
the frame; it seems to center the upper left corner. Is there an easy
way to center the frame? JDialog.setLocationRelativeTo(theDialogOwner)
also doesn't seem to center appropriately.

 

[Ben Phillips]

It didn't.

It did, sort of. For whatever reason, the server would not actually post
it until it saw a subsequent incoming post from me, and then it posted
both. So if I hadn't posted a second copy, it wouldn't have posted the
first until I'd gotten around to posting something unrelated.

Why the server behaved in that manner is likely to forever remain a mystery.

 

[Lew]

It did, sort of. For whatever reason, the server would not actually post
it until it saw a subsequent incoming post from me, and then it posted
both. So if I hadn't posted a second copy, it wouldn't have posted the
first until I'd gotten around to posting something unrelated.

Why the server behaved in that manner is likely to forever remain a mystery.

No mystery at all. It takes messages a while to be posted on the
server. When you refreshed your view of the newsgroup by posting a
second time, it updated your local ability to see the post.

The server didn't do anything weird except take a little while. The
fault, Dear Brutus, is not in our servers but in ourselves for being
so impatient.

 

[Ben Phillips]

No mystery at all. It takes messages a while to be posted on the
server. When you refreshed your view of the newsgroup by posting a
second time, it updated your local ability to see the post.

This particular server normally posts messages within 2 seconds. (I
don't know how quickly they get out to other servers, but Google usually
shows them within 2 minutes.)

I had just posted two or three other posts, and all of them appeared
when I refreshed the list. Only the one didn't, and I waited over ten
minutes and refreshed it again before concluding that something had gone
horribly wrong.

That it appeared instantly when I posted a new post, and not for the
preceding ~12 minutes, indicates a causal relationship between its
finally appearing and my making a new post, but it is NOT that my
newsreader only loaded new posts from the server when I posted again. It
doesn't load new posts at all unless I tell it to, and I told it to
right after the first post, during the 12 or so minutes after, and again
right before making the second attempt, and it didn't show up. And 2
seconds later (since the second attempt was made primarily by copying
and pasting from the sent items folder) both showed up.

The server didn't do anything weird except take a little while.

The detailed facts, above, seem to indicate otherwise. Besides taking a
"little while", it took an additional seven or so minutes above and
beyond a "little while", AND it apparently required a new post to be
made to "dislodge" the "stuck" one.

I've seen the exact same malfunction in vending machines, where a candy
bar gets stuck at the edge of the coil-thingy and won't fall out, but if
you order another one, they both come tumbling out. (Why have one when
you can have two at twice the price? )

It's just strange to see it happen in a cybernetic context. After all,
there's no coil-thingy to mechanically jam...

The fault, Dear Brutus, is not in our servers but in ourselves for being
so impatient.

12 minutes, when you've posted dozens of messages with the same server
over the preceding few months without any taking longer than 12 seconds,
is alarming.

P.S. In response to your other post re: javadocs, see my response
directly to Nigel's post.