Hi Pavel,
I can't disable DNS caching on thousands of windows PCs and the DNS is
doing it's job admirably.
I have just done the OCA and sent it to Oracle abd I am now trying to
get a sane environment for tyrus development in eclipse but I am getting
the following errors:
No marketplace entries found to handle
jetty-maven-plugin:9.2.1.v20140609:start in Eclipse. Please see Help
for more information.
No marketplace entries found to handle
maven-istack-commons-plugin:2.6.1:rs-gen in Eclipse. Please see Help
for more information.
No marketplace entries found to handle maven-jaxb-plugin:1.1.1:generate
in Eclipse. Please see Help for more information.
I'm not a maven expert by any stretch of the imagination and I have no
idea what to to here so I just told eclipse to "resolve it later".
Any tips on how to resolve this would be great.
Thanks,
Bill
On 22/11/16 15:41, Pavel Bucek wrote:
> Hi Bill,
>
> then it seems more like fixing a bug of DNS server (or workarounding
> the existence of the cache).
>
> Anyway, I can see that having similar functionality in Tyrus itself
> can be beneficial - feel free to file an enhancement request [1] and
> optionally, you can even contribute this (if you sign Oracle
> Contributor Agreement [2]). Implementing this can be relatively
> simple, you can extend existing client container (see existing ones -
> JDK and grizzly based)
>
> Since you have this setup already somewhere - if you can run more
> tests there, can you test how HttpUrlConnection behaves in this
> situation?
>
> Regards,
> Pavel
>
> [1] https://java.net/jira/browse/TYRUS
> [2] http://www.oracle.com/technetwork/community/oca-486395.html
>
>
> On 20/11/2016 19:50, Bill Mair wrote:
>> Hi Pavel,
>>
>> my problem is in the JDK Client Connector
>> (https://java.net/projects/tyrus/sources/code/content/containers/jdk-client/src/main/java/org/glassfish/tyrus/container/jdk/client/JdkClientContainer.java?rev=d86f5679c524ae65ba9254306c413acce1e51c85)
>>
>>
>> The getSocketAddress method only delivers a single SocketAddress and if
>> the first IP address returned is the server that is unavailable then the
>> client is completely incapable of connecting to the alternate address.
>>
>> Windows appears to cache the query for the TTL duration and always
>> delivers the addresses in the same order, even if the DNS is set up to
>> round robin.
>>
>> So connectSynchronously always fails when the first address in the
>> possible addresses for a server can't be reached.
>>
>> In my opinion, the client should be using
>> InetAddress#getAllByName(String host) to get multiple addresses (if
>> defined) and attempt to connect to them all in the returned order.
>>
>> One could argue that the SocketChannel in TransportFilter#handleConnect
>> should try all the available addresses but that is obviously not the
>> case.
>>
>> Maybe the completion handler could use an array of the available
>> addresses.
>>
>> --
>>
>> Bill