I think we need to completely review and rework that part anyway. LieGrue, strub
> Am 13.06.2016 um 16:27 schrieb Romain Manni-Bucau <[email protected]>: > > Up? > Le 3 juin 2016 18:22, "Romain Manni-Bucau" <[email protected]> a écrit : > >> FYI: https://issues.apache.org/jira/browse/TOMEE-1823 >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 2016-06-02 12:34 GMT+02:00 Romain Manni-Bucau <[email protected]>: >> >>> Hi guys, >>> >>> ATM in org.apache.johnzon.core.JsonStreamParserImpl#copyCurrentValue we >>> throw ArryOutOfBoundException is the read string is larger than our max >>> size. >>> >>> From JAX-RS users I got several complains we should tolerate overflow in >>> a smoother manner. Having to size the buffer at the startup is generally >>> hard (always too big or small) even if it gives a big performance boost >>> IIRC. >>> >>> Originally I designed this code to also protect against too big values >>> but wonder if we shouldn't relax it and just create another buffer on the >>> fly (we just need to ensure we return the provided buffer to the cache and >>> likely log a debug message we did that). >>> >>> wdyt? >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>> <http://www.tomitribe.com> | JavaEE Factory >>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> >> >>
