Author |
Message |
13/11/2014 13:18:01
|
afahrmann
Active
Joined: 08/10/2014 08:29:06
Messages: 7
Offline
|
Dear community!
I have a filedownloadbutton which works as expected. However, when I press "Cancel" on the popup that appears during file download, the popup closes, but the download continues in the background. Only when bytes to the resulting file are written (that's not when flushing the stream), a SocketException occurs. When the user starts a new download after cancellation but before the SocketException, the Servlet runs twice within two different threads which leads to unexpected behaviour.
Is it possible to install an actionListener to the cancel button?
I also observed, that the actionListener of the filedownloadbutton is not called when starting the download. When is it called?
Any help is appreciated. Many thanks in advance,
Andreas
Filename |
popup.PNG |
Download
|
Description |
popup with cancel button |
Filesize |
19 Kbytes
|
Downloaded: |
327 time(s) |
|
|
|
27/11/2014 13:23:18
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5527
Offline
|
...sorry, I forgot to respond to this issue.
@Events
The ACTIONLISTENER is only called at successful end of update, and only if WITHCALLBACK is defined. At the moment of download, the URL behind the component is accessed, there is no further communication with the server at this point of time.
@Cancel
In addition to closing the download info popup we explicitly interrupt the receiving of data. This means our client side looping for data gets interrupted and the corresponding streams are closed.
Code:
Loop is:
while (true)
{
if (m_interrupt == true)
{
CLog.L.log(CLog.LL_INF,"Interrupt was triggered, now throwing exception");
throw new Exception("Interrupted");
}
int maxn = 1000;
byte[] portion = new byte[maxn];
int n = in.read(portion);
IN case of Exception:
finally
{
try { os.close(); } catch (Throwable t) {}
try { in.close(); } catch (Throwable t) {}
}
...which at a certain point of time should then cause the SocketException that you mention.
So, from my perspective there is at least some "clean closing" in addition to closing the popup. ;-)
For a quick solution I would implement some interruption mechanism on your server side download-program-part. If a second download is started then the first one should be interrupted.
What type of download are you using, IBufferedContentAsStream?
If so: Here the interrupt should be done in the "writeStream(...)" method.
Regards, Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
27/11/2014 14:50:37
|
afahrmann
Active
Joined: 08/10/2014 08:29:06
Messages: 7
Offline
|
Hello Björn,
thanks a lot for answering the topic.
I guess you mean IBufferedStreamContent. That's what we are using. And yes, we have implemented some exception handling within the write()-method.
But we were not able to delete the incomplete downloaded file. That's what we still would like to implement. But we only have access to the OutputStream, not to the file or file name. A method DefaultBufferedStreamContent.getFileName() would help. Or is there another way to do this?
Regards,
Andreas
|
|
|
27/11/2014 15:00:46
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5527
Offline
|
Hi,
well, this is a good idea: to delete the file that is partially written. This is a function that I will add to the download processing as default behavior.
...will be part of next update (or fast by interim update: just tell me if you want to have it earlier!).
Regards, Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
27/11/2014 16:17:24
|
afahrmann
Active
Joined: 08/10/2014 08:29:06
Messages: 7
Offline
|
Hi Björn,
that's great. Then we just have to wait for the next update. An interim update is not necessary.
Regards,
Andreas
|
|
|
02/12/2014 10:46:01
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5527
Offline
|
...the deletion of the file is part of update 20141201(_2).
Regards, Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
|