Mule
  1. Mule
  2. MULE-3785

Cache queues/topics looked up from JNDI

    Details

    • User impact:
      Medium
    • Effort points:
      1
    • Similar Issues:
      MULE-3384No way to look up queue/topic via JNDI for Mule 2.0
      MULE-3858Topic destinations with slashes in the name can't be looked up in JNDI
      MULE-2927Allows Mule objects and components to be shared through JNDI
      MULE-1001MuleEndpoint from JndiDestination
      MULE-5285DataTypeFactory should cache instances
      MULE-1256JNDI names are not picked up for Mule JCA under Weblogic
      MULE-2235ObjectFactories should provide a way to look up object instances
      MULE-2414Wrong mule-test-exclusions.txt is being looked up
      MULE-3317SedaService inconsistently uses queue member variable and name to look up queue
      MULE-4470WeblogicJmsConnector: set username and password from connector in jndi properties

      Description

      The current implementation looks up a queue/topic from JNDI every time a message is being dispatched or received from it. We could cache the result of JNDI lookups and expose some JMX functionality to purge that cache

        Issue Links

          Activity

          Hide
          Andrew Perepelytsya added a comment -

          Spring's jndi lookup factories already provide caching.

          Show
          Andrew Perepelytsya added a comment - Spring's jndi lookup factories already provide caching.
          Hide
          Dirk Olmes added a comment -

          Spring's JNDI stuff doesn't have retry functionality, however. And we cannot use Spring in core because it has to work spring-less.

          Show
          Dirk Olmes added a comment - Spring's JNDI stuff doesn't have retry functionality, however. And we cannot use Spring in core because it has to work spring-less.
          Hide
          Andrew Perepelytsya added a comment -

          On the other hand, I'm yet to be convinced about the benefit of such caching. Need those performance numbers from profiler, otherwise it's more troublesome than beneficial.

          Show
          Andrew Perepelytsya added a comment - On the other hand, I'm yet to be convinced about the benefit of such caching. Need those performance numbers from profiler, otherwise it's more troublesome than beneficial.
          Hide
          Ross Mason added a comment -

          I think caching would make a difference since depending on the JNDI directory we may be making a network hit for every message

          Show
          Ross Mason added a comment - I think caching would make a difference since depending on the JNDI directory we may be making a network hit for every message
          Hide
          Andrew Perepelytsya added a comment -

          Just FYI, when we did profile Mule for very intensive operations with WMQ at a customer, the LDAP destinations lookup hit was negligent, down to a point where it could be ignored.

          Show
          Andrew Perepelytsya added a comment - Just FYI, when we did profile Mule for very intensive operations with WMQ at a customer, the LDAP destinations lookup hit was negligent, down to a point where it could be ignored.
          Hide
          Angelo Bresci added a comment -

          That's very good to know. Can you provide specific statistics? What were the average times, and across how many samples?

          Thanks!

          Show
          Angelo Bresci added a comment - That's very good to know. Can you provide specific statistics? What were the average times, and across how many samples? Thanks!
          Hide
          Andrew Perepelytsya added a comment -

          Don't remember exact numbers (after all, that's why it was negligent), but if e.g. the slowest operation was 150ms, the jndi lookup was like 4ms.

          Show
          Andrew Perepelytsya added a comment - Don't remember exact numbers (after all, that's why it was negligent), but if e.g. the slowest operation was 150ms, the jndi lookup was like 4ms.

            People

            • Assignee:
              Pablo Kraan
              Reporter:
              Dirk Olmes
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 1 day
                1d
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development