-
-
Notifications
You must be signed in to change notification settings - Fork 818
Add BufferRecyclerProvider
configuration
#1083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
package com.fasterxml.jackson.core.util; | ||
|
||
import com.fasterxml.jackson.core.TokenStreamFactory; | ||
|
||
/** | ||
* Provider for {@link BufferRecycler}s to allow pluggable and optional | ||
* recycling of underlying input/output buffers. | ||
* | ||
* @since 2.16 | ||
*/ | ||
public interface BufferRecyclerProvider | ||
extends java.io.Serializable | ||
{ | ||
public abstract BufferRecycler acquireBufferRecycler(TokenStreamFactory forFactory); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,6 +2,7 @@ | |
|
||
import java.lang.ref.SoftReference; | ||
|
||
import com.fasterxml.jackson.core.TokenStreamFactory; | ||
import com.fasterxml.jackson.core.io.JsonStringEncoder; | ||
|
||
/** | ||
|
@@ -61,7 +62,11 @@ public class BufferRecyclers | |
* Main accessor to call for accessing possibly recycled {@link BufferRecycler} instance. | ||
* | ||
* @return {@link BufferRecycler} to use | ||
* | ||
* @deprecated Since 2.16 should use {@link BufferRecyclerProvider} abstraction instead | ||
* of calling static methods of this class | ||
*/ | ||
@Deprecated // since 2.16 | ||
public static BufferRecycler getBufferRecycler() | ||
{ | ||
SoftReference<BufferRecycler> ref = _recyclerRef.get(); | ||
|
@@ -180,4 +185,33 @@ public static void quoteAsJsonText(CharSequence input, StringBuilder output) { | |
public static byte[] quoteAsJsonUTF8(String rawText) { | ||
return JsonStringEncoder.getInstance().quoteAsUTF8(rawText); | ||
} | ||
|
||
/* | ||
/********************************************************************** | ||
/* Default BufferRecyclerProvider implementations | ||
/********************************************************************** | ||
*/ | ||
|
||
public static BufferRecyclerProvider defaultProvider() { | ||
return ThreadLocalBufferRecyclerProvider.INSTANCE; | ||
} | ||
|
||
/** | ||
* Default {@link BufferRecyclerProvider} implementation that uses | ||
* {@link ThreadLocal} for recycling instances. | ||
* | ||
* @since 2.16 | ||
*/ | ||
public static class ThreadLocalBufferRecyclerProvider | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Was going back and forth between creating a main-level class vs nested here; mostly located here to keep close to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that it's better to keep all default implementations in one place and have them internal to the main level class. By the way we will also need another implementation not pooling anything but simply returning a new There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was wondering about "no-op" implementation but for now it did not seem necessary. But maybe I am wrong. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh. The reason -- maybe not great one -- was that the check for "do not recycle" is using a simple Feature, and by-passes provider/pool altogether. Maybe using and passing no-op instance would make more sense, nonetheless, instead of using |
||
implements BufferRecyclerProvider | ||
{ | ||
private static final long serialVersionUID = 1L; | ||
|
||
public final static ThreadLocalBufferRecyclerProvider INSTANCE = new ThreadLocalBufferRecyclerProvider(); | ||
|
||
@Override | ||
public BufferRecycler acquireBufferRecycler(TokenStreamFactory forFactory) { | ||
return getBufferRecycler(); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't sure of naming for get/return etc, open to different names than acquire/release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naming wise I believe that what's wrong here is the name of the class. The fact that is a pool should be reflected in its name, so we should call it
BufferRecyclerPool
. Once you do thisacquire
andrelease
will be the most natural choices, but of course I'm open to other suggestions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmh. Ok. Not sure how I managed to miss this comment before merging.
I agree that if there's life-cycle, "provider" is not quite the right choice.
Not sure I like "pool" but maybe that'd be better...
Let me first merge things as they are and the consider renaming.