[rfc][icedtea-web] Check online detection even if checked before

[Jiri Vanek]

On 01/06/2015 09:19 PM, Jacob Wisor wrote:
> On 01/06/2015 at 01:25 PM Jacob Wisor wrote:
>> On 01/05/2015 at 05:19 PM Jie Kang wrote:
>>> Hello,
>>>
>>> This patch slightly modifies JNLPRuntime's online detection function to
>>> always perform the check, even if it has been called before.

As Jacob is mentioning, this really is causing performance overkill.
>>>
>>> Previously, if the boolean onlineDetected wasn't null, the check would be
>>> skipped. This caused a bug when downloading multiple resources.

The idea of the check was, that first resource to be downloaded, is mostly the most crucial - jnlp, 
jnlpHref, mainclass, jar with main class... So this one have to be downlaoded - if it is not, then 
we can assume the network inaccessible.
>>>
>>> For each resource being downloaded, we perform the detection check. For two
>>> consecutive resources: If for the first resource, we detected offline, the
>>> boolean onlineDetected would be set to false. Then for the second resource,
>>> the detection check would be skipped, even if that resource was able to be
>>> connected to. This would result in the second resource being unable to be
>>> downloaded, even though it definitely could and should be. The patch fixes
>>> this.

Do you have some example of this behavior causing any real issues?
Maybe just sync the method or otherwise ensure that while isOnline is null, only one download can be 
done?

>>>
>>> Thoughts?
>>
>> Although I did not test it, seems to be working as advertised.
>>
>> While looking at the code, I was wondering why JNLPRuntime.onlineDetected was
>> a Boolean object instead of a primitive. And, apart from that, the whole
>> offline detection mechanism seems overly complex and unreliable to me.
>> I am also not really convinced that
>>
>>      public static void detectOnline(URL location) {
>>          if (onlineDetected != null) {
>>              return;
>>          }
>>          try {
>>              if (location.getProtocol().equals("file")) {
>>                  return;
>>              }
>>              //Checks the offline/online status of the system.
>>              InetAddress.getByName(location.getHost());
>>          } catch (UnknownHostException ue) { […]
>>
>> is the best or most reliable way in J2SE to test for the online/offline status
>> of a system. Do systems having no DNS server configured or which is unreachable
>> properly resolve their name? And, even if they do, does this really actually
>> prove them being online?
>>
>> Now, I was considering a few different options to reliably detecting a system's
>> online/offline status. Initially, I was thinking about pinging the default
>> gateway. However, hosts with public IPs may have their public IP as the default
>> gateway configured. So, the most reliable way I came up with is to send an echo
>> broadcast (on the local subnet) request. Of course, this does not prove the
>> system being connected to the /public/ internet. But this is not neccessary
>> either because JNLP applications may be (which they often are) served on an
>> intranet only. So, would you mind investigating this further?

Before doing this  looks-really-stupid  InetAddress.getByName(location.getHost()); i was elaborating 
on this, and have nnot found a generic way how to veryfi online status from java.
>
> Oh, I forgot: I am sure we do not want to make a DNS request for every resource
> we need to download, even when subsequent DNS resolution requests are pulled

yah, to much correct.
> from the local DNS cache. So, although this patch fixes the bug, it is very
> inefficient and impractical because it induces an avoidable performance penalty.
> In other words, the online detection *logic* itself needs to be fixed.
>
> @Jie Kang:
> Thank you for spotting this bug.
>

Is it really an bug? It actually eliminates the benefits of offline environment.

 >>> consecutive resources: If for the first resource, we detected offline, the
 >>> boolean onlineDetected would be set to false. Then for the second resource,
 >>> the detection check would be skipped, even if that resource was able to be
 >>> connected to. This would result in the second resource being unable to be
 >>> downloaded, even though it definitely could and should be. The patch fixes
 >>> this.

Thinking about it - how it is possible that first resource could not be downloaded, but second can 
be, and how it is possible that first one can be missed, while second one not?


Maybe before deciding that environment i onnline/offline - we may try to download two or three 
resources?


J.