Hi, >From our tests a while ago, Fast 1 was unusable on complex cases, too many serialization errors.
Fast 2 was better but still a lot of weird things going on on full load (our Wicket serialization requirements were heavy, but, well, that's why we were looking for faster alternatives to the default serializer). The Fast 2 developer was pretty reactive to fix bugs but we were unable to spot the last issues we had as they were only reproducible in production with full load. Removing Fast 1 looks like a good thing to do, I wouldn't recommend it at all on a real application. FWIW, we had also quite a lot of issues with Kryo in our case (and it was far far slower than the default implementation in our case). But it was a few years ago. Thought this feedback could be useful to take an educated decision. Reminds me of the good old days :). -- Guillaume On Tue, Feb 20, 2018 at 12:33 PM, Andrea Del Bene <[email protected]> wrote: > I'm also feeling quite uncomfortable with all the <wicketstuff-module>n and > they tend to be very difficult and time-expensive to maintain. I would > suggest to support only the last version for fast and kryo in the master > branch. In addition it looks like kryo has evolved pretty much lately. I > see now we have version 4 out. > > > On Sun, Feb 18, 2018 at 1:36 PM, Maxim Solodovnik <[email protected]> > wrote: > > > Hello All, > > > > We currently have come commented modules in wicketstuff: > > <!-- > > Commented because its build fails > > <module>console-parent</module> > > --> > > <!--<module>yui</module>--> > > <!--<module>yui-examples</module>--> > > > > Maybe it is time for clean-up? > > > > > > One more question: > > We have "coupled" modules: > > serializer-fast > > serializer-fast2 > > > > serializer-kryo > > serializer-kryo2 > > > > Maybe it is time to select one of them for master branch? > > > > -- > > WBR > > Maxim aka solomax > > >
