Обсуждение: NIO support
OK, I finally have first try of NIO support in the patch attached.
Vitalii Tymchyshyn
The only current feature is query timeout without any additional threads. Please note that current driver has a bug: JDBC specs says timeout is in seconds and driver takes it as millis, fixed in my patch.
Also current query timeout schema limitation is that query timeout processing still requires server round trips that are not under timeout control. I really don't see how much this differ from simply setting server-side timeout for fast connections. For slow connections it's still unreliable. Good thing that it is may be possible to enforce some kind of hard timeout with NIO schema as it's easy to control blocking calls.
Limitations: only for V3 non-secure connections. Other connections use regular stream-based implementation.
Planned features:
* SSL with NIO. This should allow to receive notifications without server roundtrip in SSL mode
* Read answer while sending query. This should make go away the problem when large query is blocked because answer must be read to send more data to server.
Note that I have never worked with CVS and have problems to make patch with new files (AFAICS I can't add it to CVS with RO access).
Comments are welcome.
P.S. To work with SSL I need to start SSL tests. Any hints?
--
Best regards,Vitalii Tymchyshyn
Вложения
Can you confirm that this patch is just to add time out ? If not can you outline what problem you are trying to solve ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca 2012/1/19 Віталій Тимчишин <tivv00@gmail.com>: > OK, I finally have first try of NIO support in the patch attached. > The only current feature is query timeout without any additional threads. > Please note that current driver has a bug: JDBC specs says timeout is in > seconds and driver takes it as millis, fixed in my patch. > Also current query timeout schema limitation is that query timeout > processing still requires server round trips that are not under timeout > control. I really don't see how much this differ from simply setting > server-side timeout for fast connections. For slow connections it's still > unreliable. Good thing that it is may be possible to enforce some kind of > hard timeout with NIO schema as it's easy to control blocking calls. > Limitations: only for V3 non-secure connections. Other connections use > regular stream-based implementation. > Planned features: > * SSL with NIO. This should allow to receive notifications without server > roundtrip in SSL mode > * Read answer while sending query. This should make go away the problem > when large query is blocked because answer must be read to send more data to > server. > > Note that I have never worked with CVS and have problems to make patch with > new files (AFAICS I can't add it to CVS with RO access). > Comments are welcome. > P.S. To work with SSL I need to start SSL tests. Any hints? > > -- > Best regards, > Vitalii Tymchyshyn > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc >
Hello. This patch provides timeouts without additional threads. I am going to enhance it to additionally solve next problems (as for me this problem are easily solvable with NIO): 1) DeadLock when client and server send buffers fill up. This is rare case because it requires query to start generation output (e.g. notices) before all query data is sent to server. AFAIR this can be provoked by copying to table with trigger outputting notices. 2) When SSL is enabled, getNotifications does not return notifications until server is asked for anything. Also move to NIO may produce better performance, but this is still something to be checked. It may be needed to select carefully if Heap or Off-heap buffers should be used to get performance benefit. P.S. Unrelated to NIO, current setQueryTimeout code has bug since it treats timeout as being specified in milliseconds, while javadoc says it's in seconds. 20.01.12 14:05, Dave Cramer написав(ла): > Can you confirm that this patch is just to add time out ? > > If not can you outline what problem you are trying to solve ? > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>: >> OK, I finally have first try of NIO support in the patch attached. >> The only current feature is query timeout without any additional threads. >> Please note that current driver has a bug: JDBC specs says timeout is in >> seconds and driver takes it as millis, fixed in my patch. >> Also current query timeout schema limitation is that query timeout >> processing still requires server round trips that are not under timeout >> control. I really don't see how much this differ from simply setting >> server-side timeout for fast connections. For slow connections it's still >> unreliable. Good thing that it is may be possible to enforce some kind of >> hard timeout with NIO schema as it's easy to control blocking calls. >> Limitations: only for V3 non-secure connections. Other connections use >> regular stream-based implementation. >> Planned features: >> * SSL with NIO. This should allow to receive notifications without server >> roundtrip in SSL mode >> * Read answer while sending query. This should make go away the problem >> when large query is blocked because answer must be read to send more data to >> server. >> >> Note that I have never worked with CVS and have problems to make patch with >> new files (AFAICS I can't add it to CVS with RO access). >> Comments are welcome. >> P.S. To work with SSL I need to start SSL tests. Any hints? >> >> -- >> Best regards, >> Vitalii Tymchyshyn >> >> >> -- >> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-jdbc >>
Vitalii, Does this compile and run on java 1.4 ? Thanks for the note on the current bug. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote: > Hello. > > This patch provides timeouts without additional threads. > I am going to enhance it to additionally solve next problems (as for me this > problem are easily solvable with NIO): > 1) DeadLock when client and server send buffers fill up. This is rare case > because it requires query to start generation output (e.g. notices) before > all query data is sent to server. AFAIR this can be provoked by copying to > table with trigger outputting notices. > 2) When SSL is enabled, getNotifications does not return notifications until > server is asked for anything. > > Also move to NIO may produce better performance, but this is still something > to be checked. It may be needed to select carefully if Heap or Off-heap > buffers should be used to get performance benefit. > > P.S. Unrelated to NIO, current setQueryTimeout code has bug since it treats > timeout as being specified in milliseconds, while javadoc says it's in > seconds. > > 20.01.12 14:05, Dave Cramer написав(ла): > >> Can you confirm that this patch is just to add time out ? >> >> If not can you outline what problem you are trying to solve ? >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> >> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>: >>> >>> OK, I finally have first try of NIO support in the patch attached. >>> The only current feature is query timeout without any additional threads. >>> Please note that current driver has a bug: JDBC specs says timeout is in >>> seconds and driver takes it as millis, fixed in my patch. >>> Also current query timeout schema limitation is that query timeout >>> processing still requires server round trips that are not under timeout >>> control. I really don't see how much this differ from simply setting >>> server-side timeout for fast connections. For slow connections it's still >>> unreliable. Good thing that it is may be possible to enforce some kind of >>> hard timeout with NIO schema as it's easy to control blocking calls. >>> Limitations: only for V3 non-secure connections. Other connections use >>> regular stream-based implementation. >>> Planned features: >>> * SSL with NIO. This should allow to receive notifications without >>> server >>> roundtrip in SSL mode >>> * Read answer while sending query. This should make go away the problem >>> when large query is blocked because answer must be read to send more data >>> to >>> server. >>> >>> Note that I have never worked with CVS and have problems to make patch >>> with >>> new files (AFAICS I can't add it to CVS with RO access). >>> Comments are welcome. >>> P.S. To work with SSL I need to start SSL tests. Any hints? >>> >>> -- >>> Best regards, >>> Vitalii Tymchyshyn >>> >>> >>> -- >>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-jdbc >>> >
20.01.12 16:06, Dave Cramer написав(ла): > Vitalii, > > Does this compile and run on java 1.4 ? I will check, but it should. NIO was introduced in 1.4 > Thanks for the note on the current bug. > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn<tivv00@gmail.com> wrote: >> Hello. >> >> This patch provides timeouts without additional threads. >> I am going to enhance it to additionally solve next problems (as for me this >> problem are easily solvable with NIO): >> 1) DeadLock when client and server send buffers fill up. This is rare case >> because it requires query to start generation output (e.g. notices) before >> all query data is sent to server. AFAIR this can be provoked by copying to >> table with trigger outputting notices. >> 2) When SSL is enabled, getNotifications does not return notifications until >> server is asked for anything. >> >> Also move to NIO may produce better performance, but this is still something >> to be checked. It may be needed to select carefully if Heap or Off-heap >> buffers should be used to get performance benefit. >> >> P.S. Unrelated to NIO, current setQueryTimeout code has bug since it treats >> timeout as being specified in milliseconds, while javadoc says it's in >> seconds. >> >> 20.01.12 14:05, Dave Cramer написав(ла): >> >>> Can you confirm that this patch is just to add time out ? >>> >>> If not can you outline what problem you are trying to solve ? >>> >>> Dave Cramer >>> >>> dave.cramer(at)credativ(dot)ca >>> http://www.credativ.ca >>> >>> >>> >>> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>: >>>> OK, I finally have first try of NIO support in the patch attached. >>>> The only current feature is query timeout without any additional threads. >>>> Please note that current driver has a bug: JDBC specs says timeout is in >>>> seconds and driver takes it as millis, fixed in my patch. >>>> Also current query timeout schema limitation is that query timeout >>>> processing still requires server round trips that are not under timeout >>>> control. I really don't see how much this differ from simply setting >>>> server-side timeout for fast connections. For slow connections it's still >>>> unreliable. Good thing that it is may be possible to enforce some kind of >>>> hard timeout with NIO schema as it's easy to control blocking calls. >>>> Limitations: only for V3 non-secure connections. Other connections use >>>> regular stream-based implementation. >>>> Planned features: >>>> * SSL with NIO. This should allow to receive notifications without >>>> server >>>> roundtrip in SSL mode >>>> * Read answer while sending query. This should make go away the problem >>>> when large query is blocked because answer must be read to send more data >>>> to >>>> server. >>>> >>>> Note that I have never worked with CVS and have problems to make patch >>>> with >>>> new files (AFAICS I can't add it to CVS with RO access). >>>> Comments are welcome. >>>> P.S. To work with SSL I need to start SSL tests. Any hints? >>>> >>>> -- >>>> Best regards, >>>> Vitalii Tymchyshyn >>>> >>>> >>>> -- >>>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>>> To make changes to your subscription: >>>> http://www.postgresql.org/mailpref/pgsql-jdbc >>>>
Hello.
I've created a fork from your github repository as it's much easier to work with. New patch is here: https://github.com/tivv/pgjdbc/commit/4321cdb7439fa1aaddca4ba925a952792e531c82
Are there any hints/guides on running SSL tests?
Best regards, Vitalii Tymchyshyn
Are there any hints/guides on running SSL tests?
Best regards, Vitalii Tymchyshyn
20 січня 2012 р. 16:06 Dave Cramer <pg@fastcrypt.com> написав:
Vitalii,
Does this compile and run on java 1.4 ?
Thanks for the note on the current bug.On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote:
> Hello.
>
> This patch provides timeouts without additional threads.
> I am going to enhance it to additionally solve next problems (as for me this
> problem are easily solvable with NIO):
> 1) DeadLock when client and server send buffers fill up. This is rare case
> because it requires query to start generation output (e.g. notices) before
> all query data is sent to server. AFAIR this can be provoked by copying to
> table with trigger outputting notices.
> 2) When SSL is enabled, getNotifications does not return notifications until
> server is asked for anything.
>
> Also move to NIO may produce better performance, but this is still something
> to be checked. It may be needed to select carefully if Heap or Off-heap
> buffers should be used to get performance benefit.
>
> P.S. Unrelated to NIO, current setQueryTimeout code has bug since it treats
> timeout as being specified in milliseconds, while javadoc says it's in
> seconds.
>
> 20.01.12 14:05, Dave Cramer написав(ла):
>
>> Can you confirm that this patch is just to add time out ?
>>
>> If not can you outline what problem you are trying to solve ?
>>
>> Dave Cramer
>>
>> dave.cramer(at)credativ(dot)ca
>> http://www.credativ.ca
>>
>>
>>
>> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>:
>>>
>>> OK, I finally have first try of NIO support in the patch attached.
>>> The only current feature is query timeout without any additional threads.
>>> Please note that current driver has a bug: JDBC specs says timeout is in
>>> seconds and driver takes it as millis, fixed in my patch.
>>> Also current query timeout schema limitation is that query timeout
>>> processing still requires server round trips that are not under timeout
>>> control. I really don't see how much this differ from simply setting
>>> server-side timeout for fast connections. For slow connections it's still
>>> unreliable. Good thing that it is may be possible to enforce some kind of
>>> hard timeout with NIO schema as it's easy to control blocking calls.
>>> Limitations: only for V3 non-secure connections. Other connections use
>>> regular stream-based implementation.
>>> Planned features:
>>> * SSL with NIO. This should allow to receive notifications without
>>> server
>>> roundtrip in SSL mode
>>> * Read answer while sending query. This should make go away the problem
>>> when large query is blocked because answer must be read to send more data
>>> to
>>> server.
>>>
>>> Note that I have never worked with CVS and have problems to make patch
>>> with
>>> new files (AFAICS I can't add it to CVS with RO access).
>>> Comments are welcome.
>>> P.S. To work with SSL I need to start SSL tests. Any hints?
>>>
>>> --
>>> Best regards,
>>> Vitalii Tymchyshyn
>>>
>>>
>>> --
>>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>>
>
Best regards,
Vitalii Tymchyshyn
Vitalii, My github repository is not current, so it is not a good place to branch from. We require context patches to be submitted to the list The ssl tests are documented in the current docs if you check them out of the project. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca 2012/1/21 Віталій Тимчишин <tivv00@gmail.com>: > Hello. > > I've fixed 1.4.2 compiling problems (moved from PriorityQueue to TreeSet + > removed some generics). Tests pass on 1.4.2. > I've created a fork from your github repository as it's much easier to work > with. New patch is > here: https://github.com/tivv/pgjdbc/commit/4321cdb7439fa1aaddca4ba925a952792e531c82 > Are there any hints/guides on running SSL tests? > > Best regards, Vitalii Tymchyshyn > > 20 січня 2012 р. 16:06 Dave Cramer <pg@fastcrypt.com> написав: > >> Vitalii, >> >> Does this compile and run on java 1.4 ? >> >> Thanks for the note on the current bug. >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> >> On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn <tivv00@gmail.com> >> wrote: >> > Hello. >> > >> > This patch provides timeouts without additional threads. >> > I am going to enhance it to additionally solve next problems (as for me >> > this >> > problem are easily solvable with NIO): >> > 1) DeadLock when client and server send buffers fill up. This is rare >> > case >> > because it requires query to start generation output (e.g. notices) >> > before >> > all query data is sent to server. AFAIR this can be provoked by copying >> > to >> > table with trigger outputting notices. >> > 2) When SSL is enabled, getNotifications does not return notifications >> > until >> > server is asked for anything. >> > >> > Also move to NIO may produce better performance, but this is still >> > something >> > to be checked. It may be needed to select carefully if Heap or Off-heap >> > buffers should be used to get performance benefit. >> > >> > P.S. Unrelated to NIO, current setQueryTimeout code has bug since it >> > treats >> > timeout as being specified in milliseconds, while javadoc says it's in >> > seconds. >> > >> > 20.01.12 14:05, Dave Cramer написав(ла): >> > >> >> Can you confirm that this patch is just to add time out ? >> >> >> >> If not can you outline what problem you are trying to solve ? >> >> >> >> Dave Cramer >> >> >> >> dave.cramer(at)credativ(dot)ca >> >> http://www.credativ.ca >> >> >> >> >> >> >> >> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>: >> >>> >> >>> OK, I finally have first try of NIO support in the patch attached. >> >>> The only current feature is query timeout without any additional >> >>> threads. >> >>> Please note that current driver has a bug: JDBC specs says timeout is >> >>> in >> >>> seconds and driver takes it as millis, fixed in my patch. >> >>> Also current query timeout schema limitation is that query timeout >> >>> processing still requires server round trips that are not under >> >>> timeout >> >>> control. I really don't see how much this differ from simply setting >> >>> server-side timeout for fast connections. For slow connections it's >> >>> still >> >>> unreliable. Good thing that it is may be possible to enforce some kind >> >>> of >> >>> hard timeout with NIO schema as it's easy to control blocking calls. >> >>> Limitations: only for V3 non-secure connections. Other connections use >> >>> regular stream-based implementation. >> >>> Planned features: >> >>> * SSL with NIO. This should allow to receive notifications without >> >>> server >> >>> roundtrip in SSL mode >> >>> * Read answer while sending query. This should make go away the >> >>> problem >> >>> when large query is blocked because answer must be read to send more >> >>> data >> >>> to >> >>> server. >> >>> >> >>> Note that I have never worked with CVS and have problems to make patch >> >>> with >> >>> new files (AFAICS I can't add it to CVS with RO access). >> >>> Comments are welcome. >> >>> P.S. To work with SSL I need to start SSL tests. Any hints? >> >>> >> >>> -- >> >>> Best regards, >> >>> Vitalii Tymchyshyn >> >>> >> >>> >> >>> -- >> >>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >> >>> To make changes to your subscription: >> >>> http://www.postgresql.org/mailpref/pgsql-jdbc >> >>> >> > > > > > > -- > Best regards, > Vitalii Tymchyshyn
Vitalli, I've given this some thought. Without using a timer you are implementing the timeout by having the read timeout on the client end. This will leave the query running on the server. Is this what we want ? Using a timer to do this we actually cancel the query on the server. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca 2012/1/22 Dave Cramer <pg@fastcrypt.com>: > Vitalii, > > My github repository is not current, so it is not a good place to branch from. > > We require context patches to be submitted to the list > > The ssl tests are documented in the current docs if you check them out > of the project. > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > 2012/1/21 Віталій Тимчишин <tivv00@gmail.com>: >> Hello. >> >> I've fixed 1.4.2 compiling problems (moved from PriorityQueue to TreeSet + >> removed some generics). Tests pass on 1.4.2. >> I've created a fork from your github repository as it's much easier to work >> with. New patch is >> here: https://github.com/tivv/pgjdbc/commit/4321cdb7439fa1aaddca4ba925a952792e531c82 >> Are there any hints/guides on running SSL tests? >> >> Best regards, Vitalii Tymchyshyn >> >> 20 січня 2012 р. 16:06 Dave Cramer <pg@fastcrypt.com> написав: >> >>> Vitalii, >>> >>> Does this compile and run on java 1.4 ? >>> >>> Thanks for the note on the current bug. >>> >>> Dave Cramer >>> >>> dave.cramer(at)credativ(dot)ca >>> http://www.credativ.ca >>> >>> >>> >>> On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn <tivv00@gmail.com> >>> wrote: >>> > Hello. >>> > >>> > This patch provides timeouts without additional threads. >>> > I am going to enhance it to additionally solve next problems (as for me >>> > this >>> > problem are easily solvable with NIO): >>> > 1) DeadLock when client and server send buffers fill up. This is rare >>> > case >>> > because it requires query to start generation output (e.g. notices) >>> > before >>> > all query data is sent to server. AFAIR this can be provoked by copying >>> > to >>> > table with trigger outputting notices. >>> > 2) When SSL is enabled, getNotifications does not return notifications >>> > until >>> > server is asked for anything. >>> > >>> > Also move to NIO may produce better performance, but this is still >>> > something >>> > to be checked. It may be needed to select carefully if Heap or Off-heap >>> > buffers should be used to get performance benefit. >>> > >>> > P.S. Unrelated to NIO, current setQueryTimeout code has bug since it >>> > treats >>> > timeout as being specified in milliseconds, while javadoc says it's in >>> > seconds. >>> > >>> > 20.01.12 14:05, Dave Cramer написав(ла): >>> > >>> >> Can you confirm that this patch is just to add time out ? >>> >> >>> >> If not can you outline what problem you are trying to solve ? >>> >> >>> >> Dave Cramer >>> >> >>> >> dave.cramer(at)credativ(dot)ca >>> >> http://www.credativ.ca >>> >> >>> >> >>> >> >>> >> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>: >>> >>> >>> >>> OK, I finally have first try of NIO support in the patch attached. >>> >>> The only current feature is query timeout without any additional >>> >>> threads. >>> >>> Please note that current driver has a bug: JDBC specs says timeout is >>> >>> in >>> >>> seconds and driver takes it as millis, fixed in my patch. >>> >>> Also current query timeout schema limitation is that query timeout >>> >>> processing still requires server round trips that are not under >>> >>> timeout >>> >>> control. I really don't see how much this differ from simply setting >>> >>> server-side timeout for fast connections. For slow connections it's >>> >>> still >>> >>> unreliable. Good thing that it is may be possible to enforce some kind >>> >>> of >>> >>> hard timeout with NIO schema as it's easy to control blocking calls. >>> >>> Limitations: only for V3 non-secure connections. Other connections use >>> >>> regular stream-based implementation. >>> >>> Planned features: >>> >>> * SSL with NIO. This should allow to receive notifications without >>> >>> server >>> >>> roundtrip in SSL mode >>> >>> * Read answer while sending query. This should make go away the >>> >>> problem >>> >>> when large query is blocked because answer must be read to send more >>> >>> data >>> >>> to >>> >>> server. >>> >>> >>> >>> Note that I have never worked with CVS and have problems to make patch >>> >>> with >>> >>> new files (AFAICS I can't add it to CVS with RO access). >>> >>> Comments are welcome. >>> >>> P.S. To work with SSL I need to start SSL tests. Any hints? >>> >>> >>> >>> -- >>> >>> Best regards, >>> >>> Vitalii Tymchyshyn >>> >>> >>> >>> >>> >>> -- >>> >>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>> >>> To make changes to your subscription: >>> >>> http://www.postgresql.org/mailpref/pgsql-jdbc >>> >>> >>> > >> >> >> >> >> -- >> Best regards, >> Vitalii Tymchyshyn
I still call your code to send request to server with another connection, so it's same thing, simply without additional thread. Talking about query timeout, the question is what benefit do we get this way instead of server-side timeout. It server connection is stable, server-side timeout is good. If it's not - the current schema won't work property. As for me, there should be two timeouts - first one is where we start trying to stop query (either current way or by simple asking server beforehand), second - when we return from query execute call, no matter if we could cancel query. Latter may lead to connection close. 31.01.12 16:29, Dave Cramer написав(ла): > Vitalli, > > I've given this some thought. Without using a timer you are > implementing the timeout by having the read timeout on the client end. > This will leave the query running on the server. Is this what we want > ? Using a timer to do this we actually cancel the query on the server. > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > 2012/1/22 Dave Cramer<pg@fastcrypt.com>: >> Vitalii, >> >> My github repository is not current, so it is not a good place to branch from. >> >> We require context patches to be submitted to the list >> >> The ssl tests are documented in the current docs if you check them out >> of the project. >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> >> 2012/1/21 Віталій Тимчишин<tivv00@gmail.com>: >>> Hello. >>> >>> I've fixed 1.4.2 compiling problems (moved from PriorityQueue to TreeSet + >>> removed some generics). Tests pass on 1.4.2. >>> I've created a fork from your github repository as it's much easier to work >>> with. New patch is >>> here: https://github.com/tivv/pgjdbc/commit/4321cdb7439fa1aaddca4ba925a952792e531c82 >>> Are there any hints/guides on running SSL tests? >>> >>> Best regards, Vitalii Tymchyshyn >>> >>> 20 січня 2012 р. 16:06 Dave Cramer<pg@fastcrypt.com> написав: >>> >>>> Vitalii, >>>> >>>> Does this compile and run on java 1.4 ? >>>> >>>> Thanks for the note on the current bug. >>>> >>>> Dave Cramer >>>> >>>> dave.cramer(at)credativ(dot)ca >>>> http://www.credativ.ca >>>> >>>> >>>> >>>> On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn<tivv00@gmail.com> >>>> wrote: >>>>> Hello. >>>>> >>>>> This patch provides timeouts without additional threads. >>>>> I am going to enhance it to additionally solve next problems (as for me >>>>> this >>>>> problem are easily solvable with NIO): >>>>> 1) DeadLock when client and server send buffers fill up. This is rare >>>>> case >>>>> because it requires query to start generation output (e.g. notices) >>>>> before >>>>> all query data is sent to server. AFAIR this can be provoked by copying >>>>> to >>>>> table with trigger outputting notices. >>>>> 2) When SSL is enabled, getNotifications does not return notifications >>>>> until >>>>> server is asked for anything. >>>>> >>>>> Also move to NIO may produce better performance, but this is still >>>>> something >>>>> to be checked. It may be needed to select carefully if Heap or Off-heap >>>>> buffers should be used to get performance benefit. >>>>> >>>>> P.S. Unrelated to NIO, current setQueryTimeout code has bug since it >>>>> treats >>>>> timeout as being specified in milliseconds, while javadoc says it's in >>>>> seconds. >>>>> >>>>> 20.01.12 14:05, Dave Cramer написав(ла): >>>>> >>>>>> Can you confirm that this patch is just to add time out ? >>>>>> >>>>>> If not can you outline what problem you are trying to solve ? >>>>>> >>>>>> Dave Cramer >>>>>> >>>>>> dave.cramer(at)credativ(dot)ca >>>>>> http://www.credativ.ca >>>>>> >>>>>> >>>>>> >>>>>> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>: >>>>>>> OK, I finally have first try of NIO support in the patch attached. >>>>>>> The only current feature is query timeout without any additional >>>>>>> threads. >>>>>>> Please note that current driver has a bug: JDBC specs says timeout is >>>>>>> in >>>>>>> seconds and driver takes it as millis, fixed in my patch. >>>>>>> Also current query timeout schema limitation is that query timeout >>>>>>> processing still requires server round trips that are not under >>>>>>> timeout >>>>>>> control. I really don't see how much this differ from simply setting >>>>>>> server-side timeout for fast connections. For slow connections it's >>>>>>> still >>>>>>> unreliable. Good thing that it is may be possible to enforce some kind >>>>>>> of >>>>>>> hard timeout with NIO schema as it's easy to control blocking calls. >>>>>>> Limitations: only for V3 non-secure connections. Other connections use >>>>>>> regular stream-based implementation. >>>>>>> Planned features: >>>>>>> * SSL with NIO. This should allow to receive notifications without >>>>>>> server >>>>>>> roundtrip in SSL mode >>>>>>> * Read answer while sending query. This should make go away the >>>>>>> problem >>>>>>> when large query is blocked because answer must be read to send more >>>>>>> data >>>>>>> to >>>>>>> server. >>>>>>> >>>>>>> Note that I have never worked with CVS and have problems to make patch >>>>>>> with >>>>>>> new files (AFAICS I can't add it to CVS with RO access). >>>>>>> Comments are welcome. >>>>>>> P.S. To work with SSL I need to start SSL tests. Any hints? >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Vitalii Tymchyshyn >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >>>>>>> To make changes to your subscription: >>>>>>> http://www.postgresql.org/mailpref/pgsql-jdbc >>>>>>> >>> >>> >>> >>> -- >>> Best regards, >>> Vitalii Tymchyshyn
Hello.
Fortunatelly official repository is available now, so I did move my commit to it. It moved clean. Also I did manage to run SSL tests. There were some quirks, so I have a small commit to documentation/example configs to make everything simplier next time: https://github.com/tivv/pgjdbc/commit/a9ae2d6d54019fac2c22f80d9671a6c4e376f2b4.
I hope now there is no need to attach commit here. I can still do this if you wish. Now I am going to continue with SSL.
Best regards, Vitalii Tymchyshyn
--
Best regards,
Vitalii Tymchyshyn
22 січня 2012 р. 13:57 Dave Cramer <pg@fastcrypt.com> написав:
Vitalii,
My github repository is not current, so it is not a good place to branch from.
We require context patches to be submitted to the list
The ssl tests are documented in the current docs if you check them out
of the project.
2012/1/21 Віталій Тимчишин <tivv00@gmail.com>:> Hello.
>
> I've fixed 1.4.2 compiling problems (moved from PriorityQueue to TreeSet +
> removed some generics). Tests pass on 1.4.2.
> I've created a fork from your github repository as it's much easier to work
> with. New patch is
> here: https://github.com/tivv/pgjdbc/commit/4321cdb7439fa1aaddca4ba925a952792e531c82
> Are there any hints/guides on running SSL tests?
>
> Best regards, Vitalii Tymchyshyn
>
> 20 січня 2012 р. 16:06 Dave Cramer <pg@fastcrypt.com> написав:
>
>> Vitalii,
>>
>> Does this compile and run on java 1.4 ?
>>
>> Thanks for the note on the current bug.
>>
>> Dave Cramer
>>
>> dave.cramer(at)credativ(dot)ca
>> http://www.credativ.ca
>>
>>
>>
>> On Fri, Jan 20, 2012 at 8:54 AM, Vitalii Tymchyshyn <tivv00@gmail.com>
>> wrote:
>> > Hello.
>> >
>> > This patch provides timeouts without additional threads.
>> > I am going to enhance it to additionally solve next problems (as for me
>> > this
>> > problem are easily solvable with NIO):
>> > 1) DeadLock when client and server send buffers fill up. This is rare
>> > case
>> > because it requires query to start generation output (e.g. notices)
>> > before
>> > all query data is sent to server. AFAIR this can be provoked by copying
>> > to
>> > table with trigger outputting notices.
>> > 2) When SSL is enabled, getNotifications does not return notifications
>> > until
>> > server is asked for anything.
>> >
>> > Also move to NIO may produce better performance, but this is still
>> > something
>> > to be checked. It may be needed to select carefully if Heap or Off-heap
>> > buffers should be used to get performance benefit.
>> >
>> > P.S. Unrelated to NIO, current setQueryTimeout code has bug since it
>> > treats
>> > timeout as being specified in milliseconds, while javadoc says it's in
>> > seconds.
>> >
>> > 20.01.12 14:05, Dave Cramer написав(ла):
>> >
>> >> Can you confirm that this patch is just to add time out ?
>> >>
>> >> If not can you outline what problem you are trying to solve ?
>> >>
>> >> Dave Cramer
>> >>
>> >> dave.cramer(at)credativ(dot)ca
>> >> http://www.credativ.ca
>> >>
>> >>
>> >>
>> >> 2012/1/19 Віталій Тимчишин<tivv00@gmail.com>:
>> >>>
>> >>> OK, I finally have first try of NIO support in the patch attached.
>> >>> The only current feature is query timeout without any additional
>> >>> threads.
>> >>> Please note that current driver has a bug: JDBC specs says timeout is
>> >>> in
>> >>> seconds and driver takes it as millis, fixed in my patch.
>> >>> Also current query timeout schema limitation is that query timeout
>> >>> processing still requires server round trips that are not under
>> >>> timeout
>> >>> control. I really don't see how much this differ from simply setting
>> >>> server-side timeout for fast connections. For slow connections it's
>> >>> still
>> >>> unreliable. Good thing that it is may be possible to enforce some kind
>> >>> of
>> >>> hard timeout with NIO schema as it's easy to control blocking calls.
>> >>> Limitations: only for V3 non-secure connections. Other connections use
>> >>> regular stream-based implementation.
>> >>> Planned features:
>> >>> * SSL with NIO. This should allow to receive notifications without
>> >>> server
>> >>> roundtrip in SSL mode
>> >>> * Read answer while sending query. This should make go away the
>> >>> problem
>> >>> when large query is blocked because answer must be read to send more
>> >>> data
>> >>> to
>> >>> server.
>> >>>
>> >>> Note that I have never worked with CVS and have problems to make patch
>> >>> with
>> >>> new files (AFAICS I can't add it to CVS with RO access).
>> >>> Comments are welcome.
>> >>> P.S. To work with SSL I need to start SSL tests. Any hints?
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Vitalii Tymchyshyn
>> >>>
>> >>>
>> >>> --
>> >>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> >>> To make changes to your subscription:
>> >>> http://www.postgresql.org/mailpref/pgsql-jdbc
>> >>>
>> >
>
>
>
>
> --
> Best regards,
> Vitalii Tymchyshyn
Best regards,
Vitalii Tymchyshyn