This content has been marked as final. Show 5 replies
Isn't is possible to check whether a connection to a Peer is still active by calling boolean Peer.isClosed()? If it has been closed, you will then have to re-establish the connection before sending the DIAMETER requests. Potentially boolean Connection.isClosed() could also be an option. I think you should try these out together with you server side.
For DPRs, and as far as I can see, theya should be possible to detect by overriding the rcvMessage(Message msg) of the com.bea.wcp.diameter.Application class.
Please let me know if I missed something.
thank you for your responce.
However, I'm still wondering if there any mechanizm exist to iterate over session objects opened over failed peer connection. It would be logical, if peer object in the case of connection lost iterate through related sessions and calls some session's method. It would allow to notify upper applications about session fail and destroy session related resources.
In the case of peer.isclose() use it should be call at every sendReq / rsvReq and connection fail detection should cause the process to iterate over opened sessions - it's less suitable then if such an iteration is done by peer object.
As for DPR, it arrives with appId=0, indicating diameter common messaging, so even as we created application with id=0, and override the method, DPR was not captured here. It seems as it's processed by node object and isn't propagated to other objects.
As far as I can see, there is no built in functionality for iterating over sessions in the OCCAS DIAMETER API, so this will have to be handled in the plug-in logic.
As for DPR, it seems like the message will arrive either to the Application or to the Session dependent on whether there is a Session-Id AVP available or not (http://download.oracle.com/docs/cd/E17645_01/doc.50/e17648/dia_diameter_base.htm#i1086737). I assume you have overridden the Application.rcvMessage(), or?
Could you also try overriding Session.rcvMessage, to see if this is where the DPR will arrive?
ok, I'll try to handle connection loss in the higher layer over OCCAS DIAMETER API.
As for DPR, I overrode rcvRequest and rcvAnswer in Application class because as I can see the DPR message have no Session-Id AVP inside. (Docs: "If there is no Session-Id AVP present, or if the session cannot be located, the Diameter application's rcvMessage() method is called"). It seems overriding Session's methods is not required.
The connection lost is a low-layer event, so it is not intended to be exposed to application layer.
There is a request timeout mechanism which will notify application/session layer for error sending. Application can utilize request.send(long timeout) API to specify a timeout value, or use request.send() API which uses global request-timeout configuration. When any error occurs (like connection lost, peer not available), a notification answer with detailed reason will notify application/session.
The DPR/DPA messages are designed to be handled internally by Diameter stack and not be dispatched to application/session layer. Application should have no way to receive DPR/DPA messages.
Edited by: user8028232 on Apr 6, 2011 12:21 AM