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.kuliche...@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 <yzhda...@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 <skoz...@gridgain.com>: > > > > > What's about to use the port range like TcpDiscoveryVmIpFinder? > > > > > > On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov <yzhda...@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 <isap...@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 > > > > > >
