OCI_GetTimeout() always returns 0 since v4.7.0

[Farzin Monsef]

After calling SetTimeout I expect GetTimeout to return 1000. but the return value is 0.

platform and version:

• OS: ubuntu-server-22.04.1
• architecture: x86_64
• Compiler: gcc10
• Oracle instant client: 19.18.0.0.0
• ocilib: 4.7.4

here is my code:

ocilib::Connection _con;
unsigned int _wt = 1000;

_con.Open(_sid, _user, _password);
_con.SetTimeout(ocilib::Connection::TimeoutType::Type::TimeoutSend, _wt);
_con.SetTimeout(ocilib::Connection::TimeoutType::Type::TimeoutReceive, _wt);
std::this_thread::sleep_for(std::chrono::seconds(1));

std::cout << "TimeoutSend: " << _con.GetTimeout(ocilib::Connection::TimeoutType::Type::TimeoutSend) << std::endl;
std::cout << "TimeoutReceive: " << _con.GetTimeout(ocilib::Connection::TimeoutType::Type::TimeoutReceive) << std::endl;

output:

TimeoutSend: 0
TimeoutReceive: 0

[Vincent Rogier]

Hi,

can you report the return values of the following calls ?

Environment::GetCompileMajorVersion()
Environment::GetRuntimeMajorVersion()
con.GetServerMajorVersion()
con.GetServerMinorVersion()
con.GetServerRevisionVersion()
con.GetVersion()

Regards,

Vincent

[Vincent Rogier]

And also :

Environment::GetCompileVersion()
Environment::GetRuntimeVersion()

[Farzin Monsef]

Hi
here is the result:

GetCompileMajorVersion: 18
GetRuntimeMajorVersion: 18
GetCompileVersion: 180100
GetRuntimeVersion: 180300
con.GetServerMajorVersion: 19
con.GetServerMinorVersion: 11
con.GetServerRevisionVersion: 0
con.GetVersion: 180300

[Vincent Rogier]

Hi,

I found the issue, a bug introduced few versions ago :(
I will fix this asap in a v4.7.6 branch.

Regards,

Vincent

[Vincent Rogier]

I fixed my bug and I was testing the different timeout types (send, receive and call)
It works now with send and call types (oracle returns the correct value previously set) but for receive type the oracle client does not fill input the variable content that should receive the value ....
I have to determine if the value for receive type is taken into account when set and if its just the oracle client getter call for this attribute that has a bug. In this case, I can store theses values in the connection object instead of relying solely on the oracle client.
.
I will reach out to this weird behavior by with 21c client to oracle folks.

[Vincent Rogier]

regression introduced in v4.7.0
Fix will be committed this evening in v4.7.6 branch
Still investigating weird OCI client behavior when getting the receive timeout

[Vincent Rogier]

Did some more testing and it seems that there is an issue in the Oracle client (at least, the one I am using windows 64bit 21.3)

[Vincent Rogier]

Hi,

v4.7.6 released.

I am waiting for feedback from Oracle about the receive timeout retrieval that does not work with 21C.

Regards,

Vincent

[Farzin Monsef]

Thank you Vincent, I appreciate your efforts.

[Vincent Rogier]

@inPhraZ If you initialize OCILIB in threaded mode ( Environment::Initialize(Environment::Threaded) ), then retrieving receive timeout works.
It seems that OCI client returns the receive timeout only if it has been initialized in threaded mode, while for other timeouts, it makes no difference.
I have send some pure OCI test case demoing the issue to Oracle. So, for me, the issue is still on the OCI client side.
I will update this issue once I get feedback from Oracle.

Regards,

Vincent

[Farzin Monsef]

If you initialize OCILIB in threaded mode ( Environment::Initialize(Environment::Threaded) ), then retrieving receive timeout works.

yes. both send and receive are working well in v4.7.6. (we did test the TimeoutCall and it also works in OCI_18_1)
but it does not apply on previous branches, cause we have been initialized with Environment::Initialize(Environment::Default | Environment::Threaded); since v4.7.4.