ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sapego <isap...@gridgain.com>
Subject Re: ODBC processor default behaviour
Date Tue, 08 Nov 2016 12:11:47 GMT
Denis,

Good point. I'll do that.

Best Regards,
Igor

On Tue, Nov 8, 2016 at 1:42 AM, Denis Magda <dmagda@gridgain.com> wrote:

> Thanks to this old discussion I was finally able to form an understanding
> on how Ignite ODBC driver connects to the cluster and executes SQL queries
> over it.
>
> *Igor*, by some reason we didn’t add any information around ODBC
> processor and configuration to our documentation page. Let’s fill this gap.
> https://issues.apache.org/jira/browse/IGNITE-4184
>
> —
> Denis
>
> On Feb 23, 2016, at 3:04 AM, Sergi Vladykin <sergi.vladykin@gmail.com>
> wrote:
>
> I think both approaches are ok if the odbc client understands how should it
> deal with connection failures (should it go through a port range or retry a
> single port during the period of time).
>
> Sergi
>
> 2016-02-23 4:35 GMT+03:00 Valentin Kulichenko <
> valentin.kulichenko@gmail.com
>
> :
>
>
> I think the behavior of OdbcProcessor should be consistent with
> RestProcessor. It tries a configurable range of ports, binds to the first
> available and prints it out in the log.
>
> -Val
>
> On Sat, Feb 20, 2016 at 7:33 AM, Yakov Zhdanov <yzhdanov@apache.org>
> wrote:
>
> Not sure if it works. DB connection string should have certain port
>
> afaik.
>
>
> --Yakov
>
> 2016-02-20 18:26 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com>:
>
> What's about to use the port range like TcpDiscoveryVmIpFinder?
>
> On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yzhdanov@apache.org>
> wrote:
>
> How about outputting warning like and keep retrying in a background
>
> thread?
>
>
> warning - "Failed to bind ODBC processor TCP server to port (retrying
>
> every
>
> 2 sec) [port=ABC]
>
> --Yakov
>
> 2016-02-20 17:38 GMT+03:00 Igor Sapego <isapego@gridgain.com>:
>
> Igniters,
>
> I'm currently working on the ODBC driver. It connects by TCP to the
> OdbcProcessor
> on the node side. OdbcProcessor is enabled by default and it starts
>
> TCP
>
> server on the
> specific TCP port or throws exception if the port is busy.
>
> The problem is that such behavior breaks tests that start more than
>
> one
>
> node on the
> same machine as the second node fails to start because ODBC port is
>
> already
>
> taken
> by the first node.
>
> Does anyone has ideas what is the best way to fix that?
>
> Best Regards,
> Igor
>
>
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message