When Connection parameters are not correct the call to eventQueue.dispatch(....) hangs and never ...

...throws an exception.

Hi,

The code snippet at the bottom works perfectly when the connection parametes such as name of the ads server, the port and Dacs-User-Id is correct.

But as soon as I change the Dacs-User-Id to a an incorrect one, the call to dispatch hangs and if there has been a successful connection prior to connection that makes the code to hang, the successful connection is destroyed and not events(updates) are dispatched from the existing successful connection. So in simple words submitting a connection with erroneous parameters will cause the program to hang and if the Dispatchable.INFINITE_WAIT is changed to 2000 milliseconds then it will return but as the result the call directoryClient.getServices() returns no services and worst of all the perviously successful RSSL-Connections gets corrupted in the same instance of the the app.

I have somehow the same setup for SSL code ( slightly different though ) below which works perfectly if when trying to connect and having a wrong parameter like DACS-User-Id. This means that eventually an exception is thrown and the code would never hang. Also perviously created and existing SSL Connections do not get corrupted and the clients that have registered their interest would easily re-register new insterests and work as expected.

Anyone who could shed some light on this issue? Would appreciated your expreties and help. Many thanks in advance.

In both cases(SSL and RSSL) the session has been creaed using

session = Session.acquire(connectionParameters);
and also
session.createEventSource(..... ) has been created to get a consumer.
try {  

eventGroup.dispatch(EventQueue.INFINITE_WAIT);

}
catch (Exception e) {

logger.error("Error on listener thread. Error dispatching Event group.", e);

}

========

RSSL Version

========

try {

request.setMsgType(OMMMsg.MsgType.STREAMING_REQ);
request.setMsgModelType(RDMMsgTypes.DIRECTORY);
OMMAttribInfo attribInfo = pool.acquireAttribInfo();
attribInfo.setFilter(
RDMService.Filter.INFO
| RDMService.Filter.STATE
| RDMService.Filter.GROUP );
request.setAttribInfo(attribInfo);

OMMItemIntSpec spec = new OMMItemIntSpec();
spec.setMsg(request);

EventQueue eventQueue = EventQueue.create("directoryQueue");
directoryHandle = ommConsumer.registerClient(eventQueue, spec, directoryClient, null);
eventQueue.dispatch(Dispatchable.INFINITE_WAIT);


} catch (Exception e) {

//Handling the exception

}

List<RMDSService> services = directoryClient.getServices();

for(RMDSService service : services) {

availableServices.put(service.getName(), service);

}


return services;

Tagged:

Best Answer

  • wasin.w
    wasin.w admin
    Answer ✓

    Hi @AMofidy-Rouhi

    If the API cannot connect to the ADS server because the wrong IP or wrong RSSL port, the application will receive the LOGIN REFRESH_RESP with the following attributes from the API via the processEvent function.

    • Msg Type: MsgType.REFRESH_RESP
    • Msg Model Type: LOGIN
    • Stream state: OPEN
    • Data state: SUSPECT
    • Status Code: NONE
    • Status Text: "All connections pending"

    And the RFA trace file (need to be enabled) shows the following message:

    Thread: <your session> Session EventQueueGroup

    Connection 0

    RSSL Connection failed for <IP>: null //Wrong IP

    or

    RSSL Connection failed for <IP>: Connection refused: no further information //Wrong Port

    I have tested with the RFA Java 7.6.1's StarterConsumer example and it works fine without any freeze or hang, the processEvent receives the above response successfully.

    Could you pleaes test with the RFA Java StarterConsumer example?

    What is the version of RFA and the Java that you are using?

    Why did you code put the eventQueue.dispatch(Dispatchable.INFINITE_WAIT); statement there? Regarding section 9.2.6.1 "Receiving Inbound Events", the dispatch method typically called within a loop. Please see an example in the RFA Java StarterConsumer example.

Answers

  • Hi @AMofidy-Rouhi

    Basically, the API returns the error message as a status response (STATUS_RESP) to the application when an invalid DACS ID is used.

    If that DACS ID does not have a permission to access ADS,t he API returns the following to the application and it stops establish a connect to the ADS.

    • Stream state: Closed
    • Data state: Suspect
    • Status Code: USER_UNKNOWN_TO_PERM_SYS
    • Status Text: "User <Username> is not registered" or "<Username> unknown to system."

    If that DACS ID does not have a permission to request data, The API returns the following message to the application and that item request stream is closed.

    • Stream state: Closed
    • Data state: Suspect
    • Status Code: Not Entitled
    • Status Text: <depending on each permission issue>

    Example status text: "Access Denied: User req to IDN for Exch - <XXX>" or "A21: DACS denied access to Vendor due to missing Vendor table", etc

    Does the application handles the above status messages from the API?

  • @Wasin
    Waeosir Thanks for your response. I have to let you know that it is not only
    the DACS-ID that causes my consumer app to freeze. Anything that makes the connection to go wrong (
    worng port number, wrong IP for the ADS.. etc...) causes my consumer
    application to freez.In regards to your answer I have to let you know
    that the implementation for processEvent (...) of the Client interface does not
    even get called for me to check the Status.

  • Hi @AMofidy-Rouhi I did not receive any updates for a while. Can you replicate the issue with the RFA Java StarterConsumer example?