johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: valueBuffer update/rework?
Date Wed, 07 Jun 2017 05:59:08 GMT
PS: compared quickly to the RI and I think they are worse than us since
they use buffers of 4096 chars but if it is too small they auto adjust
doubling the size (like ArrayList a bit) but they recycle (release in
johnzon) all buffers which means that for a string of 4097 chars it will
allocate 12288 chars and keep them (even if their queue is a
WeakReference). For big payload - sending a README.md for instance which
can be huuuge - they will allocate way more than us which is very bad,
however they auto adjust which is something we prevented to ensure the
application controls the memory (originally).

So just migrating our strategy to an auto extensible impl sounds fine, we
should however probably define the allocation step (if we start with a
buffer of 64k for instance I would increase it by step of 8k  or even just
4k maybe and not double it - another property?). Also think we should
recycle the original buffer but not the overriden ones. Finally it would
probably makes sense to log a warning saying we allocate more than the
configuration was designed for but if it happens to each request it can
pollute logs for nothing really hurting so maybe just log it once each
minute or something like that.

wdyt?



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-07 7:37 GMT+02:00 Romain Manni-Bucau <rmannibucau@gmail.com>:

> Hi guys,
>
> one criticism we often have is our max string length or in code terms
> valueBuffer allocation which is not very flexible since we allocate a
> buffer of the max string length and with our queue strategy (default) it
> leads to #threads * buffer size and lead to OOME if the application uses
> some big strings.
>
> One option can be to replace our fallbackCopyBuffer of JsonStreamParser by
> a plain StringBuilder or extensible char[] structure and completely drop
> our valueBuffer.
>
> Anyone wants to test it - main thing to test to avoid regression is about
> performances?
>
> Alternative is to change the valueBuffer from a char[] provider to a
> ArrayStructure<char> (to define in johnzon) and have multiple
> implementations, one backed by a plain array like today, one with the
> extensible structure etc and just change our default to use the extensible
> structure but we could still use the plain array for perf reasons.
>
> wdyt? Anyone motivated?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message