GeoServer

Add a thread local cache of proxied configuration objects

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 2.1.x
  • Component/s: Configuration
  • Labels:
    None
  • Number of attachments :
    0

Description

From IRC:

aaime: ok, so to sum up, to solve the issue cleanly we need
aaime: - a new catalog object interface
aaime: - a per thread ModificationProxy cache
aaime: - a mechanism to clean it up when the current request ends

Issue Links

depends upon

Task - A task that needs to be done. GEOS-2764 Add a root interface for all catalog and config objects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. GEOS-3051 ModificationProxy does not maintain equals/hashcode contract of the wrapped objects

  • Major - Major loss of function.
  • 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
Jody Garnett added a comment -

Made it here? Wow, you're persistent!

What kind of pun is that?

Show
Jody Garnett added a comment - Made it here? Wow, you're persistent! What kind of pun is that?
Hide
Permalink
Andrea Aime added a comment -

Jody, what are you talking about??
The idea is a good one.

Show
Andrea Aime added a comment - Jody, what are you talking about?? The idea is a good one.
Hide
Permalink
Andrea Aime added a comment -

Oh, btw, the therad local must be cleared when the request ends. A dispatcher callback could be tempting, but would cover the OWS paths only.
I guess we need a servlet filter (or a Spring equivalent, if any) that will run against all and every possible request... err... and that would still leave out stuff that is not tied to requests
e.g., we do have a timer that periodically invokes a runnable in WCS to clean up the temporary storage directory... that does not fiddle with the catalog, but a different one could

Show
Andrea Aime added a comment - Oh, btw, the therad local must be cleared when the request ends. A dispatcher callback could be tempting, but would cover the OWS paths only. I guess we need a servlet filter (or a Spring equivalent, if any) that will run against all and every possible request... err... and that would still leave out stuff that is not tied to requests e.g., we do have a timer that periodically invokes a runnable in WCS to clean up the temporary storage directory... that does not fiddle with the catalog, but a different one could
Hide
Permalink
Justin Deoliveira added a comment -

Agreed.I prefer not to use a servlet filter, as those seem to be more geared toward things that are configurable, or something a user might want to turn off. A spring request interceptor should do the same thing and not have to be thrown into web.xml.

Show
Justin Deoliveira added a comment - Agreed.I prefer not to use a servlet filter, as those seem to be more geared toward things that are configurable, or something a user might want to turn off. A spring request interceptor should do the same thing and not have to be thrown into web.xml.

People

  • Assignee:
    Justin Deoliveira
    Reporter:
    Justin Deoliveira
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: