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

[Jiri Vanek]

On 01/21/2015 10:28 AM, Jiri Vanek wrote:
> 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?
>
>
>

One more thing crossed my mind - if the check is done everytime ressource is download.

Then the output of isOnline() method is actually prety undetermined.


?


J.