You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating jruby/jruby#3151, a few issues with the way Caching does delegation came to light:
At least one place, in conditional_on_changes_to, an HTTP::Request object gets double-delegated. Both the self.class.new and .caching calls wrap the new HTTP::Request object in a delegating Caching instance.
The Caching class itself is created before HTTP::Request has completed loading, resulting in a DelegateClass that does most delegation through method_missing rather than through generated, direct delegation methods.
These issues are not strictly bugs, but they likely affect performance. In the case of jruby/jruby#3151, they also exposed an obscure bug in JRuby.
The text was updated successfully, but these errors were encountered:
I'm not really happy with the quality of the caching code. It's caused a lot of sporadic test failures. Having a dependency on rack isn't really something I like either.
Perhaps we could remove it and add it back when/if it's in a better state?
While investigating jruby/jruby#3151, a few issues with the way
Caching
does delegation came to light:conditional_on_changes_to
, anHTTP::Request
object gets double-delegated. Both theself.class.new
and.caching
calls wrap the newHTTP::Request
object in a delegatingCaching
instance.Caching
class itself is created beforeHTTP::Request
has completed loading, resulting in aDelegateClass
that does most delegation throughmethod_missing
rather than through generated, direct delegation methods.These issues are not strictly bugs, but they likely affect performance. In the case of jruby/jruby#3151, they also exposed an obscure bug in JRuby.
The text was updated successfully, but these errors were encountered: