You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Igor Sapego <is...@gridgain.com> on 2016/02/20 15:38:56 UTC
ODBC processor default behaviour
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
Re: ODBC processor default behaviour
Posted by Igor Sapego <is...@gridgain.com>.
Denis,
Good point. I'll do that.
Best Regards,
Igor
On Tue, Nov 8, 2016 at 1:42 AM, Denis Magda <dm...@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 <se...@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 <yz...@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 <sk...@gridgain.com>:
>
> What's about to use the port range like TcpDiscoveryVmIpFinder?
>
> On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yz...@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 <is...@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
>
>
>
>
>
Re: ODBC processor default behaviour
Posted by Denis Magda <dm...@gridgain.com>.
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 <https://issues.apache.org/jira/browse/IGNITE-4184>
—
Denis
> On Feb 23, 2016, at 3:04 AM, Sergi Vladykin <se...@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 <yz...@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 <sk...@gridgain.com>:
>>>
>>>> What's about to use the port range like TcpDiscoveryVmIpFinder?
>>>>
>>>> On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yz...@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 <is...@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
>>>>
>>>
>>
Re: ODBC processor default behaviour
Posted by Sergi Vladykin <se...@gmail.com>.
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 <yz...@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 <sk...@gridgain.com>:
> >
> > > What's about to use the port range like TcpDiscoveryVmIpFinder?
> > >
> > > On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yz...@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 <is...@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
> > >
> >
>
Re: ODBC processor default behaviour
Posted by Valentin Kulichenko <va...@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 <yz...@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 <sk...@gridgain.com>:
>
> > What's about to use the port range like TcpDiscoveryVmIpFinder?
> >
> > On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yz...@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 <is...@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
> >
>
Re: ODBC processor default behaviour
Posted by Yakov Zhdanov <yz...@apache.org>.
Not sure if it works. DB connection string should have certain port afaik.
--Yakov
2016-02-20 18:26 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> What's about to use the port range like TcpDiscoveryVmIpFinder?
>
> On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yz...@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 <is...@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
>
Re: ODBC processor default behaviour
Posted by Sergey Kozlov <sk...@gridgain.com>.
What's about to use the port range like TcpDiscoveryVmIpFinder?
On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yz...@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 <is...@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
Re: ODBC processor default behaviour
Posted by Yakov Zhdanov <yz...@apache.org>.
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 <is...@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
>