Network Communication Failures

Comments

5 comments

  • Avatar
    Parker Phinney

    We are experiencing similar network connection break issues. It would be helpful to get more insight into why connection breaks occur. They are limited in the number of times they happen but frustrating because you cannot take action to prevent. 

  • Avatar
    JL Macatula

    Hmmmm interesting....  what type of errors are you getting?  And between what systems are the connections getting broken? We do experience network "hiccups" every once in a while and cannot find the root cause of it. I hate to close out an issue unsolved :(  

  • Avatar
    Parker Phinney

    Infogix Cloud and our network. I think  we know that there is a timeout setting when Assure runs too long. There should be a "Heartbeat" function coming (I believe). But there are other outages that we have not explained. Doesn't happen often, last time was in August.

     

  • Avatar
    JL Macatula

    Ahhhhh..  We haven't done an Infogix cloud to our network type of connection. What we experienced before was between our Mainframe system going to Infogix Assure. We had to adjust this field below in the Assure Server side to prevent it from getting Timeout errors. I would think there is a similar field in the Cloud Assure properties file that handles this between Cloud and your system. 

    # On/off flag for Keep alive heart beat for streaming client
    STREAMING_CLIENT_KEEP_ALIVE=true

    A common network error we also get is if we try to connect from Infogix Assure to a database source (internally). They don't come in as often anymore. And normally, if we restart the job, it goes in the second time around. And based on the errors and forums I've visited, these were mostly caused by the driver versions we are using or the Database version of the receiving system.

     

     

     

  • Avatar
    Jeffery Brown
    The heartbeat function that Parker is referring too is coming soon and will allow the Assure client to be able to invoke control point processing in the server asynchronously, without retaining a long-running socket connection while the server runs the control point, but will still wait for the control point to finish (including processing of subsequent runcp actions). It's still in development and we should have more information soon.

Please sign in to leave a comment.



Powered by Zendesk