You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Maxim Solodovnik <so...@gmail.com> on 2018/02/18 12:36:34 UTC

Clean-up of wicketstuff modules

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

Re: Clean-up of wicketstuff modules

Posted by Maxim Solodovnik <so...@gmail.com>.
OK

first iteration of the clean-up is done:
https://github.com/wicketstuff/core/commit/1db418dbea3b9aec84ad81e3474573b151954658

1) commented out modules are removed
2) versions are corrected
3) missing modules are added

now "grep -rn SNAPSHOT" provides more cleaner output

On Wed, Feb 21, 2018 at 8:53 PM, Guillaume Smet
<gu...@gmail.com> wrote:
> Hi,
>
> On Wed, Feb 21, 2018 at 2:41 PM, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> Maybe you can donate sort of test suite so we can enhance these modules?
>>
>
> I don't have access to the code anymore (left the company 2 years ago) and
> it was deeply integrated customer code anyway.
>
> The cases we elucidated are all part of the Fast 2 test suite now as we
> reported the bugs upstream and also pushed a few fixes. But we never
> succeeded in getting to the bottom of the weird and inconsistent production
> issues unfortunately.
>
> Other than that, Fast 2 was really faster than everything else in our
> situation but, in the end, we chose to stay on the safe side as having
> production bugs due to serialization was not an option.
>
> --
> Guillaume



-- 
WBR
Maxim aka solomax

Re: Clean-up of wicketstuff modules

Posted by Guillaume Smet <gu...@gmail.com>.
Hi,

On Wed, Feb 21, 2018 at 2:41 PM, Maxim Solodovnik <so...@gmail.com>
wrote:

> Maybe you can donate sort of test suite so we can enhance these modules?
>

I don't have access to the code anymore (left the company 2 years ago) and
it was deeply integrated customer code anyway.

The cases we elucidated are all part of the Fast 2 test suite now as we
reported the bugs upstream and also pushed a few fixes. But we never
succeeded in getting to the bottom of the weird and inconsistent production
issues unfortunately.

Other than that, Fast 2 was really faster than everything else in our
situation but, in the end, we chose to stay on the safe side as having
production bugs due to serialization was not an option.

-- 
Guillaume

Re: Clean-up of wicketstuff modules

Posted by Maxim Solodovnik <so...@gmail.com>.
Hello,

Maybe you can donate sort of test suite so we can enhance these modules?

On Wed, Feb 21, 2018 at 5:15 PM, Guillaume Smet
<gu...@gmail.com> wrote:
> 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 <an...@gmail.com>
> 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 <so...@gmail.com>
>> 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
>> >
>>



-- 
WBR
Maxim aka solomax

Re: Clean-up of wicketstuff modules

Posted by Guillaume Smet <gu...@gmail.com>.
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 <an...@gmail.com>
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 <so...@gmail.com>
> 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
> >
>

Re: Clean-up of wicketstuff modules

Posted by Andrea Del Bene <an...@gmail.com>.
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 <so...@gmail.com>
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
>