[unixODBC-support] Communication closed during authentication, Connection reset by peer, SQL state 28000

marco ardito ardito at apiform.to.it
Fri Jan 27 12:56:03 GMT 2017


update: it doesn't seems to be related to MSSQL, apparently...

- I created a copy of the teiid virtual database, excluding any MSSQL 
server from its models
- changed the web server config to load, through unixodbc, the new 
virtual database
- it happens again... same message: " [unixODBC]Communication closed 
during authentication; Connection reset by peer., SQL state 28000 in 
SQLConnect"

I looked for unixodbc logs, and found that this error is reported in 
many psqlodbc*.log files (I guess this name comes from the postgres 
driver usage)

And this is how it appears there (there are many files like this): 
there's a first connection try that fails with the error, then another 
one that succedes... (no timings, though...?)

can you spot any interesting info here?

=================
DSN info: 
DSN='dsnname',server='x.y.z.w',port='xxxxx',dbase='vdbname',user='user',passwd='xxxxx'
           
onlyread='No',protocol='7.4',showoid='No',fakeoidindex='No',showsystable='No'
           conn_settings='', conn_encoding='(null)'
           translation_dll='',translation_option=''
conn = 0x8058d3c8, PGAPI_Connect(DSN='dsnname', UID='user', PWD='xxxxx')
Driver Version='09.02.0100,201306020000'
Global Options: fetch=10000, socket=4096, unknown_sizes=0, 
max_varchar_size=255, max_longvarchar_size=8190
                 disable_optimizer=0, ksqo=0, unique_index=1, 
use_declarefetch=0
                 text_as_longvarchar=1, unknowns_as_longvarchar=0, 
bools_as_char=1 NAMEDATALEN=64
                 extra_systable_prefixes='dd_;', conn_settings='' 
conn_encoding=''
CONN ERROR: func=original_CC_connect, desc='', errnum=210, 
errmsg='Communication closed during authentication'
             ------------------------------------------------------------
             henv=0x8058c2b8, conn=0x8058d3c8, status=0, num_stmts=16
             sock=0x8058b160, stmts=0x80589280, lobj_type=-999
             ---------------- Socket Info -------------------------------
             socket=38, reverse=0, errornumber=10, errormsg='Connection 
reset by peer.'
             buffer_in=2153300704, buffer_out=2153316120
             buffer_filled_in=0, buffer_filled_out=0, buffer_read_in=0
CONN ERROR: func=PGAPI_Connect, desc='Error on CC_connect', errnum=210, 
errmsg='Communication closed during authentication'
             ------------------------------------------------------------
             henv=0x8058c2b8, conn=0x8058d3c8, status=0, num_stmts=16
             sock=0x8058b160, stmts=0x80589280, lobj_type=-999
             ---------------- Socket Info -------------------------------
             socket=38, reverse=0, errornumber=10, errormsg='Connection 
reset by peer.'
             buffer_in=2153300704, buffer_out=2153316120
             buffer_filled_in=0, buffer_filled_out=0, buffer_read_in=0
DSN info: 
DSN='dsnname',server='x.y.z.w',port='xxxxx',dbase='vdbname',user='user',passwd='xxxxx'
           
onlyread='No',protocol='7.4',showoid='No',fakeoidindex='No',showsystable='No'
           conn_settings='', conn_encoding='(null)'
           translation_dll='',translation_option=''
conn = 0x8058d9c8, PGAPI_Connect(DSN='dsnname', UID='user', PWD='xxxxx')
Driver Version='09.02.0100,201306020000'
Global Options: fetch=10000, socket=4096, unknown_sizes=0, 
max_varchar_size=255, max_longvarchar_size=8190
                 disable_optimizer=0, ksqo=0, unique_index=1, 
use_declarefetch=0
                 text_as_longvarchar=1, unknowns_as_longvarchar=0, 
bools_as_char=1 NAMEDATALEN=64
                 extra_systable_prefixes='dd_;', conn_settings='' 
conn_encoding=''
     [ PostgreSQL version string = '8.1.4' ]
     [ PostgreSQL version number = '8.1' ]
conn=0x8058d9c8, query='select oid, typbasetype from pg_type where 
typname = 'lo''
     [ fetched 1 rows ]
     [ Large Object oid = 14939 ]
     [ Client encoding = 'UTF8' (code = 6) ]
conn=0x8058d9c8, PGAPI_Disconnect
=================

Il 27/01/2017 09:24, marco ardito ha scritto:
> Thanks all for replying, and infos.
> From what you all wrote, it seems that the cause of the error can only 
> be a connection to a Microsoft SQL server, isn't it?
>
> If it is so, I could restrict the field of investigation... my virtual 
> database on teiid server has two different MSSQL servers behind, with 
> a slightly different network path, too. I could try disabling one of 
> them, temporarily. And maybe the really short lifespan of the issue (a 
> simple retry then works) should point towards a transient network 
> issue... instead of a dirver or configuration issue.
>
> I was in doubt about what subsystem was reporting the error (I thought 
> to ask here because it was labelled by "[unixodbc]") because, as I 
> said before, on my web server unixodbc uses only postgresql driver 
> towards teiid (it is the only "db" unixodbc sees, and connects to), 
> which in turn has several jdbc connections towards different databases 
> on different web servers (two MSSQL, one Mysql server) and also other 
> resources.
>
> If it is so, if it is really due to a connection towards a MSSQL 
> server, it should be a problem better "visible" from Teiid, and its 
> logs, since it's doing the real connection to those remote MSSQL 
> servers... and unixodbc is only reporting the remote error transparently.
>
> I will soon contact teiid support team about this, but any further 
> consideration you could add about the above will help me to better 
> understand this matter, quite new to me...
>
> Thanks a lot.
>
> Il 26/01/2017 02:27, Daniel Kasak ha scritto:
>> I'm not a heavy user, but I've done a little testing, here and there,
>> against most of the freebie versions of SQL Server, ... You could try
>> turning on ODBC tracing, examining SQL Server logs, etc. Good luck :)
>>
>> Dan
>>
>> On Thu, Jan 26, 2017 at 4:54 AM, Edouard Gaulué<listes at e-gaulue.com>  wrote:
>>> Hi,
>>>
>>> In my case, I've observed those kind of unpredictable error after moving
>>> from SQL2008 to SQL2012.
>>>
>>> Any change on the SQL Server side?
>
> -- 
> *Marco*


-- 
*Marco Ardito*
Responsabile Servizi Informatici

Api Formazione s.c.r.l.
Via Pianezza 123, 10151 - TORINO
Tel: +39-0114513123
Fax: +39-0114551150 - +39-0114515075
Mail : ardito at apiform.to.it <mailto:ardito at apiform.to.it>
Web : http://www.apiform.to.it


-------------------
[Ai sensi e per  gli  effetti della Legge sulla tutela della privacy
(L. 196/2003), questa  mail  è destinata unicamente alle persone sopra
indicate e le informazioni in essa contenute sono da considerarsi
strettamente riservate. E' proibito leggere, copiare, usare o
diffondere il contenuto della presente mail senza autorizzazione.
Se avete ricevuto questo messaggio per errore, siete pregati di
rispedire la stessa al mittente. Grazie]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20170127/e3f5057c/attachment.html>


More information about the unixODBC-support mailing list