Spring Framework
  1. Spring Framework
  2. SPR-7148

Caching of MessageProducers in CachingConnectionFactory not working with MQ

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.0.3
    • Component/s: JMS
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      The CachingConnectionFactory uses a HashMap to cache message producers. The key to the map is the Destination. Unfortunately when using MQ, the producers are cached but never retrieved, a new MesssageProducer is created and cached for each call. This eventually results in MQ raising an exception when trying to create the MessageProducer (a session limit is hit after just 253 publishes). The cache should use an explicit key (as the consumer cache does) or even Destination#toString().

        Activity

        Hide
        Ben Greenway added a comment -

        I might also add that this is quite a major issue for us. We have been upgrading spring to tie back to changed with spring-integration project, and we are in a bit of bind as to the versions of spring that we may now select from. Thankyou for your consideration in the matter. Please dont hesitate to ask any queries. I am in Australia so there may be some time lag between queries/responses.

        Show
        Ben Greenway added a comment - I might also add that this is quite a major issue for us. We have been upgrading spring to tie back to changed with spring-integration project, and we are in a bit of bind as to the versions of spring that we may now select from. Thankyou for your consideration in the matter. Please dont hesitate to ask any queries. I am in Australia so there may be some time lag between queries/responses.
        Hide
        Ben Greenway added a comment -

        In an attempt to build up a standalone test case to reproduce the error, which it did, I was also able to identify the real cause of the problem. The real cause was a piece of code, which had a session.createProducer(null) entry. Therefore the null was finding its way to the DesintationCacheKey. Obviously it makes no sense to have a producer with no destination.

        Show
        Ben Greenway added a comment - In an attempt to build up a standalone test case to reproduce the error, which it did, I was also able to identify the real cause of the problem. The real cause was a piece of code, which had a session.createProducer(null) entry. Therefore the null was finding its way to the DesintationCacheKey. Obviously it makes no sense to have a producer with no destination.
        Hide
        Juergen Hoeller added a comment -

        Good catch! createProducer's Destination argument may actually be null if you pass the actual Destination to the producer's send operation - this is rare but valid, in contrast to createConsumer which requires a non-null Destination argument.

        I've fixed CachingConnectionFactory to correctly cache a producer without fixed destination as well, as of Spring 3.0.4. This will be available in tonight's 3.0.4 snapshot... Feel free to give it a try.

        Juergen

        Show
        Juergen Hoeller added a comment - Good catch! createProducer's Destination argument may actually be null if you pass the actual Destination to the producer's send operation - this is rare but valid, in contrast to createConsumer which requires a non-null Destination argument. I've fixed CachingConnectionFactory to correctly cache a producer without fixed destination as well, as of Spring 3.0.4. This will be available in tonight's 3.0.4 snapshot... Feel free to give it a try. Juergen
        Hide
        Ben Greenway added a comment -

        Yes, looks like the code (which has been in place for about 4 years) is creating a producer, with null desitnation, then later creates a temporyQueue from the session, with the producer as a reference bound back to it.

        I have just tried the latest build, but it appears that due to our firewall rules I cannot build from source (probably due to s3://).

        I need to grab the artifacts from a snapshot. When is the next one scheduled?

        Show
        Ben Greenway added a comment - Yes, looks like the code (which has been in place for about 4 years) is creating a producer, with null desitnation, then later creates a temporyQueue from the session, with the producer as a reference bound back to it. I have just tried the latest build, but it appears that due to our firewall rules I cannot build from source (probably due to s3://). I need to grab the artifacts from a snapshot. When is the next one scheduled?
        Hide
        Ben Greenway added a comment -

        Redployed under Spring 3.0.4.CI-742 and appears at the early stages to look good. Thanks for the assistance.

        Show
        Ben Greenway added a comment - Redployed under Spring 3.0.4.CI-742 and appears at the early stages to look good. Thanks for the assistance.

          People

          • Assignee:
            Juergen Hoeller
            Reporter:
            Andrew Woodford
            Last updater:
            Trevor Marshall
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              3 years, 40 weeks, 1 day ago