URLConnection getContentLength()

Newbie & Debugging Questions
#1

It takes a long time and i want to be able to interrupt it at will. I thought just using the thread trick to turn a synchronous method into a asynchronous one would work, but apparently it never throws interrupted exception. I guess i could ignore it (by replacing the interrupt for a break in that while.

Seems wrong though. Interrupting methods is such a bother in current PL’s.


            AssynchronousGetSize r = new AssynchronousGetSize(conn);

            Thread t = new Thread(r);
            t.start();

            while(t.isAlive()){
                if(p.isClosed()){
                    //closed in the ui
                    t.interrupt();
                }
                t.join(500);
            }
#2

waht is p?

#3

My replacement for ProgressMonitor, since the jdk one likes to create components outside in the EDT (and yes the p.isClosed() internal variable is volatile).

edit, not that it need it in this case.

Edit: correction likes to create outside the EDT

#4

Try changing:

t.interrupt();

to:

conn.getInputStream().close();

or if conn is an instance of HttpURLConnection:

conn.disconnect();
#5

Start at the start: why do you want to be able to interrupt it?

#6

Because it takes a f**king long while before the application acknowledges my having pressed the cancel button if i don’t?

Basically the whole method is this:

So the progress monitor knows it should close, because it popups right away after startViewInEDT in indeterminate state. I do this for obvious usability reasons. But, now having displayed the message i need to get the real size to setTotal(max) and at the same time ack a user pressing cancel during that interval. My pattern in these edt finangles is starting in the edt and offloading larger tasks into another Thread or ExecutorService, but not here since the ProgressMonitorStream hasa ProgressMonitor not the opposite (as i think is fitting) and the ProgressMonitor hasa view (which may not be fitting but f**k it).


    public static ProgressMonitorStream create(URL url, String message, Component parent) throws IOException {
        ProgressMonitor p = new ProgressMonitor(-1, message);
        try {
            p.startViewInEDT(parent);
            final URLConnection conn = url.openConnection();
            AsynchronousGetSize r = new AsynchronousGetSize(conn);

            Thread t = new Thread(r, "AsynchronousGetSizeThread");
            t.start();
            while(t.isAlive()){
                if(p.isClosed()){
                    //closed in the ui
                    t.interrupt();
                    throw new IOException("closed progress monitor while attempting to estabilish connection");
                }
                t.join(500);
            }
            int max = r.max;
            InputStream s = new BufferedInputStream(conn.getInputStream());
            p.setTotal(max);
            return new ProgressMonitorStream(s, max, p);
        } catch (Exception ex) {
            //close the dialog... (small window of opportunnity
            //where it doesn't close when a exception happens).
            p.close();
            throw new IOException(ex);
        }
    }

As you can see i’m currrently ignoring a in progress getContentLength if i don’t care about it no more, after symbollically interrupting it- i remember reading that the old stream api doesn’t respond to interrupts except the piped stream variants. Using a thread for this looks and feels awful especially considering the amount of threads my application already uses (hopefully none left hanging by now).

#7

Folks i just noticed that this won’t work if i call it on the edt.
[s]Then the time consuming tasks are done before the dialog even shows because of the edt queue like nature. startViewInEDT justs calls invoke later showing the view.

The nature of the method should be to show the dialog the fastest possible in all situations where a progress monitor stream can be used.

Maybe i need a test in the startViewInEDT method?

if(isEDT){
r.run();
}else{
invokeLater®;
}[/s]

(currently startViewInEDT uses invokeLater)

I noticed that the setVisible method is blocking… so the rest of the code never gets executed if i used that runnable in a invokeAndWait or called it directly. Including the code that would call close in the progress monitor (and dispose the view) if it went wrong of if the stream finished. So if i execute directly or use invokeAndWait, the edt is blocked. If i used invokeLater it is not blocked, but the view only displays after getcontentLenght and the rest of the code executes. Just another threading error.
(obviously reordering the statements so the arguments needed are available before calling startViewInEDT is not viable (what happens now if the whole method is called in the EDT). The view must start right then as soon as possible (but not block the rest of the code)).

So what i really need where to make this thread safe is call the whole function code out of the EDT if needed right? But - shit - as the method has a return that is not viable either. The caller would only get the input stream after the popup window was closed.

A notifier in a inputstream static factory saying this method shall not be called in the EDT seems to trust in my ability to read javadocs a bit too much.

3 threads already - edt, one to run this P.O.S. method and the aux turn into a synchronous method into a asynchronous method one.

#8

So, because you’re doing it in the EDT? You seem already to have worked out the solution, which is not to do anything expensive in the EDT. Spawn a thread which does the IO and uses SwingUtilities.invoke* to update the UI. Or pass state between the two using volatile fields or AtomicInteger etc.

#9

No, that is not the problem. That is an hypothetical i (do) avoid.

I am trying to make it thread safe. Including being called from the edt. Which i don’t, currently.
The problem in a nutshell, disregarding the asynchronous method thing:
setVisible is blocking.
The create method might be called anywhere (its only a creation of a input stream, no matter how special).
In the EDT the statements get reordered by invokelater - the view is only made visible after it knows the size in that code, but it should be reversed like if it isn’t called in the EDT, so it takes a long time to display the view (doesn’t stop execution - invoke later would stop it because of setVisible).

Thats it. I don’t know how to avoid it, simply because setVisible is blocking (always). Maybe if i spin of the second part of the method - the one that sets the max size - into a runnable that runs conditionally off the edt if in it, and just return the input stream with a max size of 0 (the input stream size argument is for some statistics, download speed in particular - in fact i don’t need this there - its just that it was tempting to use a already made superclass that had a hook and funcionality in the right place).

But that turns a already complex method i was hoping to simplify into hideous. Maybe i should just throw a Runtime exception, especially since the getInputStream method of HTTPURLConnection takes a long time to return (connect) if it is remote, so the method would probably run slowly.

#10

There are two ways round setVisible blocking. One is to not use a modal Dialog (or to fake your own with a JFrame - IIRC you can put an invisible component in the glasspane of the parent JFrame to which you can add a listener). The other is to make setVisible the last thing you do. If you hide the dialog in the new EDT then I think setVisible will return.

If that still doesn’t make sense then please post a self-contained executable example, faking out the expensive network operation with a wait/sleep.