RAC notification service connection timeout causes very slow connection opening

[pogib]

I've noticed an issue which might be a bug or at least a possibility for improvement.
This can be reproduced with dotconnect for Oracle versions 9.14 and 9.16.

If you are connecting to an Oracle RAC and using Oracle Client with 12 or higher, when you create the connection devart tries to subscribe to the ONS notification synchronously, so if that service port is blocked (default is 6200), each connection initialization takes at least 10 seconds (until the subscription times out).

A workaround might be that you set the Min Pool Size to a number greater than 0.

For us it took quite some time to figure out what happens in the background, because the Oracle Client traces do not include useful information about this subscription timeout.

It looks like that the managed and unmanaged Oracle providers are doing this subscriptions asnychronously, so in that case the timeout appears in the console (in case of higher trace level) after you could already use their new connections.
I would assume that this might be also beneficial for dotconnect (of course in that case it is even more complicated to realize that there is a blocked port, but initializing a connection in 10s is really slow).

Probably Oracle should be writing some warning logs (I guess devart doesn't have the facility to notify the developer about this)

A bit unexpected that the following message was written to Console.Out - I guess by the Oracle unmanaged client:
ONS Error: ONS ERROR=26 subscriber 1 create failed: timedout (oracle client version 21)

or

subscriber 425700424 create failed (oracle client version 12)

[DmitryGm]

Thank you for your report. We will investigate the issue, but we will need more time to create the necessary infrastructure and reproduce the problem.