JDBC thin driver: support connection timeout

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JDBC thin driver: support connection timeout

Alexander Lapin
Hi Igniters,

Within context of connection timeout [
https://issues.apache.org/jira/browse/IGNITE-5234] it's not obvious whether
it's required to use setNetworkTimeout's executor or not.

According to the javadoc of java.sql.Connection#setNetworkTimeout(Executor
executor, int milliseconds), executor is "The <code>Executor</code>
implementation which will be used by <code>setNetworkTimeout</code>."
Seems that executor supposed to take care of connection closing/aborting in
case of timeout, based on submitted Runnable implementation. On the other
hand it's possible to ignore executor and implement
timeout-detection/cancellation logic with Timer. Something like following
(pseudo-code):

ConnectionTimeoutTimerTask connectionTimeoutTimerTask = new
ConnectionTimeoutTimerTask(timeout);
timer.schedule(connectionTimeoutTimerTask, 0, REQUEST_TIMEOUT_PERIOD);
...
JdbcResponse res = cliIo.sendRequest(req);
...

private class ConnectionTimeoutTimerTask extends TimerTask {
...
    @Override public void run() {
        if (remainingConnectionTimeout <= 0)
            close(); //connection.close();

        remainingConnectionTimeout -= REQUEST_TIMEOUT_PERIOD;
    }
...
}

It worth to mention that MSSQL Jdbc driver doesn't use executor and
PostgreSQL doesn't implement setNetworkTimeout() at all.

From my point of view it might be better to ignore executor, is it suitable?

Any ideas?
Reply | Threaded
Open this post in threaded view
|

Re: JDBC thin driver: support connection timeout

Ivan Pavlukhin
Hi Alexander,

I have 2 points.

1. According to the jdbc spec [1] setNetworkTimeout method is
optional. What user problem we are going to solve by implementing that
method?
2. Also I checked another quite popular jdbc driver provided by
MariaDB [2]. They ignore an executor argument as well and set a socket
timeout instead. So, I think that we are on a safe side if we ignore
an executor.

[1] https://download.oracle.com/otndocs/jcp/jdbc-4_2-mrel2-spec/index.html
пт, 30 нояб. 2018 г. в 16:28, Alexander Lapin <[hidden email]>:

>
> Hi Igniters,
>
> Within context of connection timeout [
> https://issues.apache.org/jira/browse/IGNITE-5234] it's not obvious whether
> it's required to use setNetworkTimeout's executor or not.
>
> According to the javadoc of java.sql.Connection#setNetworkTimeout(Executor
> executor, int milliseconds), executor is "The <code>Executor</code>
> implementation which will be used by <code>setNetworkTimeout</code>."
> Seems that executor supposed to take care of connection closing/aborting in
> case of timeout, based on submitted Runnable implementation. On the other
> hand it's possible to ignore executor and implement
> timeout-detection/cancellation logic with Timer. Something like following
> (pseudo-code):
>
> ConnectionTimeoutTimerTask connectionTimeoutTimerTask = new
> ConnectionTimeoutTimerTask(timeout);
> timer.schedule(connectionTimeoutTimerTask, 0, REQUEST_TIMEOUT_PERIOD);
> ...
> JdbcResponse res = cliIo.sendRequest(req);
> ...
>
> private class ConnectionTimeoutTimerTask extends TimerTask {
> ...
>     @Override public void run() {
>         if (remainingConnectionTimeout <= 0)
>             close(); //connection.close();
>
>         remainingConnectionTimeout -= REQUEST_TIMEOUT_PERIOD;
>     }
> ...
> }
>
> It worth to mention that MSSQL Jdbc driver doesn't use executor and
> PostgreSQL doesn't implement setNetworkTimeout() at all.
>
> From my point of view it might be better to ignore executor, is it suitable?
>
> Any ideas?



--
Best regards,
Ivan Pavlukhin
Reply | Threaded
Open this post in threaded view
|

Re: JDBC thin driver: support connection timeout

Ivan Pavlukhin
Missing ref:
[2] https://mvnrepository.com/artifact/org.mariadb.jdbc/mariadb-java-client/2.3.0

2018-12-02 18:31 GMT+03:00, Павлухин Иван <[hidden email]>:

> Hi Alexander,
>
> I have 2 points.
>
> 1. According to the jdbc spec [1] setNetworkTimeout method is
> optional. What user problem we are going to solve by implementing that
> method?
> 2. Also I checked another quite popular jdbc driver provided by
> MariaDB [2]. They ignore an executor argument as well and set a socket
> timeout instead. So, I think that we are on a safe side if we ignore
> an executor.
>
> [1] https://download.oracle.com/otndocs/jcp/jdbc-4_2-mrel2-spec/index.html
> пт, 30 нояб. 2018 г. в 16:28, Alexander Lapin <[hidden email]>:
>>
>> Hi Igniters,
>>
>> Within context of connection timeout [
>> https://issues.apache.org/jira/browse/IGNITE-5234] it's not obvious
>> whether
>> it's required to use setNetworkTimeout's executor or not.
>>
>> According to the javadoc of
>> java.sql.Connection#setNetworkTimeout(Executor
>> executor, int milliseconds), executor is "The <code>Executor</code>
>> implementation which will be used by <code>setNetworkTimeout</code>."
>> Seems that executor supposed to take care of connection closing/aborting
>> in
>> case of timeout, based on submitted Runnable implementation. On the other
>> hand it's possible to ignore executor and implement
>> timeout-detection/cancellation logic with Timer. Something like following
>> (pseudo-code):
>>
>> ConnectionTimeoutTimerTask connectionTimeoutTimerTask = new
>> ConnectionTimeoutTimerTask(timeout);
>> timer.schedule(connectionTimeoutTimerTask, 0, REQUEST_TIMEOUT_PERIOD);
>> ...
>> JdbcResponse res = cliIo.sendRequest(req);
>> ...
>>
>> private class ConnectionTimeoutTimerTask extends TimerTask {
>> ...
>>     @Override public void run() {
>>         if (remainingConnectionTimeout <= 0)
>>             close(); //connection.close();
>>
>>         remainingConnectionTimeout -= REQUEST_TIMEOUT_PERIOD;
>>     }
>> ...
>> }
>>
>> It worth to mention that MSSQL Jdbc driver doesn't use executor and
>> PostgreSQL doesn't implement setNetworkTimeout() at all.
>>
>> From my point of view it might be better to ignore executor, is it
>> suitable?
>>
>> Any ideas?
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>


--
Best regards,
Ivan Pavlukhin
Reply | Threaded
Open this post in threaded view
|

Re: JDBC thin driver: support connection timeout

Vladimir Ozerov
+1

вс, 2 дек. 2018 г. в 18:39, Павлухин Иван <[hidden email]>:

> Missing ref:
> [2]
> https://mvnrepository.com/artifact/org.mariadb.jdbc/mariadb-java-client/2.3.0
>
> 2018-12-02 18:31 GMT+03:00, Павлухин Иван <[hidden email]>:
> > Hi Alexander,
> >
> > I have 2 points.
> >
> > 1. According to the jdbc spec [1] setNetworkTimeout method is
> > optional. What user problem we are going to solve by implementing that
> > method?
> > 2. Also I checked another quite popular jdbc driver provided by
> > MariaDB [2]. They ignore an executor argument as well and set a socket
> > timeout instead. So, I think that we are on a safe side if we ignore
> > an executor.
> >
> > [1]
> https://download.oracle.com/otndocs/jcp/jdbc-4_2-mrel2-spec/index.html
> > пт, 30 нояб. 2018 г. в 16:28, Alexander Lapin <[hidden email]>:
> >>
> >> Hi Igniters,
> >>
> >> Within context of connection timeout [
> >> https://issues.apache.org/jira/browse/IGNITE-5234] it's not obvious
> >> whether
> >> it's required to use setNetworkTimeout's executor or not.
> >>
> >> According to the javadoc of
> >> java.sql.Connection#setNetworkTimeout(Executor
> >> executor, int milliseconds), executor is "The <code>Executor</code>
> >> implementation which will be used by <code>setNetworkTimeout</code>."
> >> Seems that executor supposed to take care of connection closing/aborting
> >> in
> >> case of timeout, based on submitted Runnable implementation. On the
> other
> >> hand it's possible to ignore executor and implement
> >> timeout-detection/cancellation logic with Timer. Something like
> following
> >> (pseudo-code):
> >>
> >> ConnectionTimeoutTimerTask connectionTimeoutTimerTask = new
> >> ConnectionTimeoutTimerTask(timeout);
> >> timer.schedule(connectionTimeoutTimerTask, 0, REQUEST_TIMEOUT_PERIOD);
> >> ...
> >> JdbcResponse res = cliIo.sendRequest(req);
> >> ...
> >>
> >> private class ConnectionTimeoutTimerTask extends TimerTask {
> >> ...
> >>     @Override public void run() {
> >>         if (remainingConnectionTimeout <= 0)
> >>             close(); //connection.close();
> >>
> >>         remainingConnectionTimeout -= REQUEST_TIMEOUT_PERIOD;
> >>     }
> >> ...
> >> }
> >>
> >> It worth to mention that MSSQL Jdbc driver doesn't use executor and
> >> PostgreSQL doesn't implement setNetworkTimeout() at all.
> >>
> >> From my point of view it might be better to ignore executor, is it
> >> suitable?
> >>
> >> Any ideas?
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Reply | Threaded
Open this post in threaded view
|

Re: JDBC thin driver: support connection timeout

Alexander Lapin
Hi Ivan, Vladimir,

@Ivan

> 1. According to the jdbc spec [1] setNetworkTimeout method is
> optional. What user problem we are going to solve by implementing that
> method?
>
We are going to give user an ability to set custom connection timeout.

> Also I checked another quite popular jdbc driver provided by
> MariaDB [2]. They ignore an executor argument as well and set a socket
> timeout instead. So, I think that we are on a safe side if we ignore
> an executor.
>
Got it. Thank you!

So, I'll implemented connection timeout with the help of socket timeout
ignoring an executor.

Thanks,
Alexander

пн, 3 дек. 2018 г. в 00:41, Vladimir Ozerov <[hidden email]>:

> +1
>
> вс, 2 дек. 2018 г. в 18:39, Павлухин Иван <[hidden email]>:
>
> > Missing ref:
> > [2]
> >
> https://mvnrepository.com/artifact/org.mariadb.jdbc/mariadb-java-client/2.3.0
> >
> > 2018-12-02 18:31 GMT+03:00, Павлухин Иван <[hidden email]>:
> > > Hi Alexander,
> > >
> > > I have 2 points.
> > >
> > > 1. According to the jdbc spec [1] setNetworkTimeout method is
> > > optional. What user problem we are going to solve by implementing that
> > > method?
> > > 2. Also I checked another quite popular jdbc driver provided by
> > > MariaDB [2]. They ignore an executor argument as well and set a socket
> > > timeout instead. So, I think that we are on a safe side if we ignore
> > > an executor.
> > >
> > > [1]
> > https://download.oracle.com/otndocs/jcp/jdbc-4_2-mrel2-spec/index.html
> > > пт, 30 нояб. 2018 г. в 16:28, Alexander Lapin <[hidden email]>:
> > >>
> > >> Hi Igniters,
> > >>
> > >> Within context of connection timeout [
> > >> https://issues.apache.org/jira/browse/IGNITE-5234] it's not obvious
> > >> whether
> > >> it's required to use setNetworkTimeout's executor or not.
> > >>
> > >> According to the javadoc of
> > >> java.sql.Connection#setNetworkTimeout(Executor
> > >> executor, int milliseconds), executor is "The <code>Executor</code>
> > >> implementation which will be used by <code>setNetworkTimeout</code>."
> > >> Seems that executor supposed to take care of connection
> closing/aborting
> > >> in
> > >> case of timeout, based on submitted Runnable implementation. On the
> > other
> > >> hand it's possible to ignore executor and implement
> > >> timeout-detection/cancellation logic with Timer. Something like
> > following
> > >> (pseudo-code):
> > >>
> > >> ConnectionTimeoutTimerTask connectionTimeoutTimerTask = new
> > >> ConnectionTimeoutTimerTask(timeout);
> > >> timer.schedule(connectionTimeoutTimerTask, 0, REQUEST_TIMEOUT_PERIOD);
> > >> ...
> > >> JdbcResponse res = cliIo.sendRequest(req);
> > >> ...
> > >>
> > >> private class ConnectionTimeoutTimerTask extends TimerTask {
> > >> ...
> > >>     @Override public void run() {
> > >>         if (remainingConnectionTimeout <= 0)
> > >>             close(); //connection.close();
> > >>
> > >>         remainingConnectionTimeout -= REQUEST_TIMEOUT_PERIOD;
> > >>     }
> > >> ...
> > >> }
> > >>
> > >> It worth to mention that MSSQL Jdbc driver doesn't use executor and
> > >> PostgreSQL doesn't implement setNetworkTimeout() at all.
> > >>
> > >> From my point of view it might be better to ignore executor, is it
> > >> suitable?
> > >>
> > >> Any ideas?
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>