2016-06-15 12:02 GMT+02:00 Mark Struberg <[email protected]>:
> I think we need to completely review and rework that part anyway. > > Thanks for your opinion, what about actions ;)? > 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> > >>> > >> > >> > >
