Cache queues/topics looked up from JNDI

Details

  • User impact:
    Medium
  • Effort points:
    1
  • Affects Docs:
    Yes
  • Similar Issues:
    None

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

duplicates

Improvement - An improvement or enhancement to an existing feature or task. MULE-5507 Problems when using JMS with LDAP

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Improvement - An improvement or enhancement to an existing feature or task. MULE-3384 No way to look up queue/topic via JNDI for Mule 2.0

  • Blocker - Blocks development and/or testing work, production could not run.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

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