UPA Reactor skipping "READY"

Joe.Ferraro

Occasionally after calling rsslReactorConnect, after the call completes, the worker thread waiting on the select will start to return, resulting in calls to rsslReactorDispatch and calls to the channel event callback routine.

Normally, the callback will be called with the channelEventType RSSL_RC_CET_CHANNEL_UP followed by RSSL_RC_CET_CHANNEL_READY.
At this point, the connection can be used to send queries.

In the error case howver, this is NOT happening. The RSSL_CET_RC_CHANNEL_UP events IS RECEIVED, but the RSSL_RC_CHANNEL_READY event *NEVER ARRIVES*.
Instead, after some time an RSSL_RC_CET_CHANNEL_RECONNECTING event arrives following a few passes through select/rsslReactorDispatch.
After a 1 or more RECONNECTING events, the reactor will once again invoke the callback with a RSSL_RC_CHANNEL_UP, followed by more select/rsslDispatch cycles and 1 or more RSSL_RC_CET_RECONNECTING events and the whole thing repeats.

Is this normal behavior, the result of misuse of the reactor by my code or a bug in the reactor.

Currently the only way my program can recover from this UP/RECONNECTING endless cycles is to manually restart it.
If this beahavior is part of the normal pattern of communications, that is NEVER getting a READY event, what needs to be done to successfully establish a usable connection to the reactor?

Thanks

Joe.Ferraro

This problem is caused by the same issue described in the Question:
"Calling ETA Reactor rsslReactorConnect in tight loop to stress test corrupts reactor"

The simple answer is that the rsslReactorConnect requires that the pointers to the structures it is passed must exist beyond the lifetime of the method making the call.
This means that if the structures are on the stack when the call is made, by the time the reactor services it (raector worker thread), the data may have been overwritten due to stack reuse.