cman - the misleading error message

 In my last post I showed how a human error and a misleading log entry leaded to a waste of resources and time identifying (and fixing) the problem. 

But that's not all: Oracle connection manager (cman) is providing additional sources of joy and time wasting error analysis by leading in the wrong direction.

In this case, the cman (21.3) is working fine. 

The database instance has a REMOTE_LISTENER configuration pointing to the cman. 

The service is registered in the cman (show services) and there is a proper rule for the service in place (show rules):

Still at connecting with sqlplus, an unexpected error occurs: 

sqlplus -L x/x@<MY_ALIAS>

SQL*Plus: Release 19.0.0.0.0 - Production on Do Jan 6 21:40:04 2023
Version 19.14.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

ERROR:
TNS-12529: TNS:connect request rejected based on current filtering rules

But even after checking the services and rules again, there is no visible error. 

To cut things short (and avoid moaning about lost hours of investigation), the problem is located in some unexpected configuration: 

The database instance parameter LOCAL_LISTENER was set to 

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=REGISTER_listener)))

This made totally sense as long as no cman was in use: the instance registered to it's dedicated listener and then the services were available for clients to connect to. 

http://wikiality.wikia.com/wiki/File:Bridge-to-nowhere.jpg

But in my case, rdbms instance told the cman it can handle the service MY_SERVICE (which is used in MY_ALIAS) by redirecting all connections to ipc:REGISTER_listener. Of course this listener is not available at the cman host, and so the gateway process fails miserably. 

By understanding the problem, the solution is simple: changing the database instance parameter to 

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=REGISTER_listener))),instance_host:1521

did the trick - and sqlplus was happy (at least as happy as ORA-1017 can make)

Quite simple, but it didn't map the error message 

TNS-12529: TNS:connect request rejected based on current filtering rules

at least to my standards. 

I'd prefer a statement like 

gateway couldn't establish connection for service MY_SERVICE to (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=REGISTER_listener))) 

Maybe a future release can do that trick?