Forum Discussion

Lydia's avatar
Lydia
New Contributor II
4 years ago
Solved

Error management on JMS Consumer

Hello everyone,

We are currently trying to improve our pipelines by adding error paths and are having problems with the JMS Consumer snap.
Unlike other snaps, like the SQL Server snaps, where a connection failure is routed to the error path, a connection error on our JMS snap does not trigger the error path and fails (see attached image).

Is there a way for us to catch those errors without ending with a failure ?
Please note we do not use ultra pipeline/ultra tasks, but a regular schedule task to run this pipeline.

Edit for clarity :


Error is not triggering error path


Here same type of error (connexion error) is triggering error path (don’t mine the failure on the next box it was expected here)

error_handling
  • Supratim's avatar
    Supratim
    4 years ago

    @Lydia If you want to explicitly stop your pipeline after send some action (logging/notifying) you can use EXIT snap and config till how many no of document it accept like 1 in below pic. You can also customized you error message on exit error message filed. If you config that pipeline as task and select notification in case of failure, people will get snaplogic platform generated mail with your custom error message.

17 Replies

  • ptaylor's avatar
    ptaylor
    Employee
    4 years ago

    Hi Lydia,

    Please open the Pipeline Validation Statistics, show more details for the error in that snap, and post the details here using the preformatted text feature of the editor (the </> icon). The stack trace will help us identify the cause of this issue.

    Thanks,
    Patrick

    • Lydia's avatar
      Lydia
      New Contributor II
      4 years ago

      Hi ptaylor,

      Here is the error i got. In this case i was specifically using the wrong password to trigger an authentication error.

      An error occurred while creating the consumer

Resolution:
Please verify if the provided properties like destination, message selector and subscription name are valid

Reason:
JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
Hide Details...
SnapCompletionService
com.snaplogic.api.ConfigurationException: An error occurred while creating the consumer
	at com.snaplogic.snaps.jms.JMSConsumer.executeForSuggest(JMSConsumer.java:635)
	at com.snaplogic.cc.snap.common.SnapRunnableImpl.executeSnap(SnapRunnableImpl.java:798)
	at com.snaplogic.cc.snap.common.SnapRunnableImpl.executeForSuggest(SnapRunnableImpl.java:647)
	at com.snaplogic.cc.snap.common.SnapRunnableImpl.doRun(SnapRunnableImpl.java:856)
	at com.snaplogic.cc.snap.common.SnapRunnableImpl.call(SnapRunnableImpl.java:435)
	at com.snaplogic.cc.snap.common.SnapRunnableImpl.call(SnapRunnableImpl.java:117)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: com.snaplogic.snap.api.SnapDataException: An error occurred while creating the connection from the connection factory (Name: CDP_MQ_APP1)
	at com.snaplogic.snaps.jms.JMSAccount.createConnection(JMSAccount.java:376)
	at com.snaplogic.snaps.jms.JMSAccount.createSessionRequest(JMSAccount.java:308)
	at com.snaplogic.snaps.jms.JMSAccount.connect(JMSAccount.java:223)
	at com.snaplogic.snaps.jms.JMSAccount.connect(JMSAccount.java:75)
	at com.snaplogic.snaps.jms.JMSConsumer.initSessionsForValidate(JMSConsumer.java:310)
	at com.snaplogic.snaps.jms.JMSConsumer.lambda$executeForSuggest$3(JMSConsumer.java:611)
	at net.jodah.failsafe.Functions.lambda$toSupplier$10(Functions.java:262)
	at net.jodah.failsafe.Functions.lambda$get$0(Functions.java:48)
	at net.jodah.failsafe.RetryPolicyExecutor.lambda$supply$0(RetryPolicyExecutor.java:66)
	at net.jodah.failsafe.Execution.executeSync(Execution.java:128)
	at net.jodah.failsafe.FailsafeExecutor.call(FailsafeExecutor.java:379)
	at net.jodah.failsafe.FailsafeExecutor.run(FailsafeExecutor.java:212)
	at com.snaplogic.snaps.jms.JMSConsumer.executeForSuggest(JMSConsumer.java:604)
	... 11 more
Caused by: com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for queue manager 'TAAPP1' with connection mode 'Client' and host name 'CTAMQS1.LACAISSE.COM(1417)'.
Please check if the supplied username and password are correct on the queue manager to which you are connecting.  For further information, review the queue manager error logs and the Securing IBM MQ topic within IBM Knowledge Center. 
	at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:531)
	at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:215)
	at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnection.java:439)
	at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7ProviderConnection(WMQConnectionFactory.java:8475)
	at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProviderConnection(WMQConnectionFactory.java:7815)
	at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl._createConnection(JmsConnectionFactoryImpl.java:303)
	at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createConnection(JmsConnectionFactoryImpl.java:236)
	at com.ibm.mq.jms.MQConnectionFactory.createCommonConnection(MQConnectionFactory.java:6005)
	at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:136)
	at com.ibm.mq.jms.MQQueueConnectionFactory.createConnection(MQQueueConnectionFactory.java:209)
	at com.snaplogic.snaps.jms.JMSAccount.createConnection(JMSAccount.java:374)
	... 23 more
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
	at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:203)
	... 32 more
Reason: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035'
    ('MQRC_NOT_AUTHORIZED').
Resolution: Please verify if the provided properties like destination, message selector and subscription name
    are valid

Error Fingerprint[0] = efp:com.snaplogic.snaps.jms.jP6OsCuR
Error Fingerprint[1] = efp:com.snaplogic.snaps.jms.WukNlqv9
Error Fingerprint[2] = efp:com.ibm.msg.client.wmq.common.internal.w7ghFJBL
Error Fingerprint[3] = efp:com.ibm.msg.client.wmq.common.internal._mz1O6W-

      • ptaylor's avatar
        ptaylor
        Employee
        4 years ago

        Hi Lydia. Thanks for posting the detail.

        The snap is throwing a ConfigurationException showing that the authentication failed. Most snaps handle such exceptions by immediately failing rather than writing the error to the error view. The error view is typically used for a document-specific error that may not occur for the next document. But authentication errors aren’t really appropriate here, since the only way to really “handle” them is to fix the configuration of your account and run the pipeline again.

        If the SQL snap isn’t behaving this way when using an account with a bad password, then I’d say that snap is not following our normal error handling conventions. If you gave it 1000 input documents, you’d see the 1000 copies of the same error on the error view, as it would attempt the same failed authentication over and over. That doesn’t seem ideal.

        When you ask “Is there a way for us to catch those errors without ending with a failure?”, what do you have in mind? If the account is misconfigured, isn’t ending with a failure what you would expect?

  • bojanvelevski's avatar
    bojanvelevski
    Valued Contributor
    4 years ago

    I don’t have much experience in JMS, but as I could see from the error, you don’t have the right privileges.

    MQRC 2035 (MQRC_NOT_AUTHORIZED) is returned when a user is not authorized to perform the function .

  • Lydia's avatar
    Lydia
    New Contributor II
    4 years ago

    Hi ptaylor,

    Thank you very much for this answer ! You gave me a better insight on how things work.
    And yeah it actually makes a lot of sense that i’m not catching this error. Yet at the same time being able to handle an error path and stop the pipeline instead of failing is quite different.

    Basically :

    • For the JMS snap I want to be able to direct any issue with MQ directly to MQ team cause i have no hand in it. Most issue these days are actually about a down with the MQ but i was doing quick testing on my side only so i tried with an auth failure instead. I’ll contact the MQ dev team for integrated testing to see if i can reproduce the exact error and check how snaplogic responds to that.

    • Regardless of the error/snap having an issue and of what kind, I wanted to be able to STOP the pipeline after sending a notification / logging the issue, instead of ending in a FAILURE (which is also a stop but abrupt). That’s because of how my organisation poorly deals with failures in Snaplogic i guess. Since we’re a big org with several teams using Snaplogic, right now it takes several hours for my team to be made aware of the failure of one of our pipeline in production and then i need to dig in the dashboard to find more info and it’s really not an efficent process. With an error path i can make us aware directly and with more specific info depending on where a problems occurs.

    • Supratim's avatar
      Supratim
      Contributor III
      4 years ago

      @Lydia If you want to explicitly stop your pipeline after send some action (logging/notifying) you can use EXIT snap and config till how many no of document it accept like 1 in below pic. You can also customized you error message on exit error message filed. If you config that pipeline as task and select notification in case of failure, people will get snaplogic platform generated mail with your custom error message.

      • nshrivastava's avatar
        nshrivastava
        New Contributor
        3 years ago

        Hi Experts,

        Configuring through task the notification does work in this scenario. Does this mean that this is expected to work like this only. Because clearly there is a difference in behavior between MySQL Snaps & JMS Snaps.
        Is this expected?

        Thanks.

    • Lydia's avatar
      Lydia
      New Contributor II
      4 years ago

      Hi @darshthakkar, thanks for the comeback !

      The snap works just fine usually, I was currently trying to trigger an error by using the wrong password to see if the error path was working correctly, because error caused on MQ issues needed to be foward to a different team than the team managing the rest of the pipeline in production.
      My issue is not the error itself but the fact that it doesnt go to the error path and instead fails right there.

      In comparaison when i use the wrong SQL password on the SQL snap it triggers the error path correctly :

      (dont mind the fail on the error box itself cause it’s using the same sql account 😅 )

      • darshthakkar's avatar
        darshthakkar
        Valued Contributor
        4 years ago

        Which snap is the Audit Erreur Generation... ?
        Is it a pipeline execute, JWT Validate, HTTP router or Shuffle snap?

        If its a pipeline execute, can you please check which child pipeline it’s is trying to execute?