Have a fully JMS 1.0 compatible instrumentation

[amarziali]

What Does This Do

Few methods like getDestination or getAcknoledgeMode have only been introduced with JMS 1.1. Even if muzzle guards against JMS 1.0 implementations, issues can arise when jms-api 1.1 is present in the classpath but some implementors offer a jms 1.0 implementations.

This can happen for some old IBM MQ drivers. An example:

Error : Failed to handle exception in instrumentation for com.ibm.mq.jms.MQQueueSession
java.lang.AbstractMethodError

(Others errors also point to the JmsProducerInstrumentation).

This PR uses fallback methods to deal with JMS 1.0 implementors:

• Do additional cast to use specialised Topic or Queue methods instead of the generic getDestination
• Widen to throwable then using getAcknoledgeMode. Please notice that, in order to have that information, a lot of scaffolding is needed to capture the same info with additional instrumentation. I did not judge this important if missing to have an overall acceptable level for this instrumentation.

The tests have been conducted with a JmsConnectionFactory that wraps the original and simulate the absence of key methods used in the instrumentations (please not that I deliberately delegate some methods not existing in ConnectionFactory/TopicProducer/etc in order not to rewrite the full test since they are not used in the instrumentation itself)

Motivation

Additional Notes

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors

Jira ticket: [PROJ-IDENT]

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4d0d0f6e42

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve JMS 1.0 session ack mode

When a JMS 1.0 provider uses QueueConnection.createQueueSession/TopicConnection.createTopicSession with transacted=true or Session.CLIENT_ACKNOWLEDGE, getAcknowledgeMode() is exactly the 1.1 method that raises AbstractMethodError, so this fallback records the SessionState as AUTO_ACKNOWLEDGE. JMSMessageConsumerInstrumentation only defers spans to acknowledge()/commit() when SessionState reports client-ack/transacted, and the Commit/Recover advices have the same guards, so these JMS 1.0 sessions now finish spans and time-in-queue batches with auto-ack semantics instead of the session's actual semantics. The fallback should preserve at least the transacted/client-ack mode from creation or getTransacted() rather than defaulting every error to AUTO.

Useful? React with 👍 / 👎.

[amarziali]

This has been done on purpose - the tradeoff is to have not exact time here but still having 1.0 supported. Otherwise I would have needed to instrument also javax.jms.Connection (and all the subclasses) to capture that info when createSession/createTopicSession/createQueueSession are called. And that would have been made the instrumentation way heavier just to support few library versions. The tradeoff that we have in this PR is to me acceptable