Vote: Remove FilePageStore

[Matej Knopp <ma...@gmail.com>]

Hi,

since we have DiskPageStore and it seems to work quite well and there
are known threading issues in FilePageStore which noone seems to want
to fix, I propose a vote to remove FilePageStore, as it no longer
seems to be necessary.

Thus the options are:

[  ]  Remove FilePageStore
[  ]  Keep FilePageStore, because I need it for <insert why> and
DiskPageStore doesn't cut it because <insert why>

-Matej

Re: Vote: Remove FilePageStore

[Igor Vaynberg <ig...@gmail.com>]

On 9/30/07, Matej Knopp <ma...@gmail.com> wrote:
>
> [X]  Remove FilePageStore


-igor

Re: Vote: Remove FilePageStore

[Matej Knopp <ma...@gmail.com>]

 [X]  Remove FilePageStore
 [  ]  Keep FilePageStore, because I need it for <insert why> and

-Matej

Re: Vote: Remove FilePageStore

[Johan Compagner <jc...@gmail.com>]

there is a jira for that.



On 10/22/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 10/22/07, Johan Compagner <jc...@gmail.com> wrote:
> > ok didn't know that, then it can be removed.
>
> I say, create a JIRA issue and go for it :-) Creative destruction rools!
>
> Eelco
>

Re: Vote: Remove FilePageStore

[Eelco Hillenius <ee...@gmail.com>]

On 10/22/07, Johan Compagner <jc...@gmail.com> wrote:
> ok didn't know that, then it can be removed.

I say, create a JIRA issue and go for it :-) Creative destruction rools!

Eelco

Re: Vote: Remove FilePageStore

[Johan Compagner <jc...@gmail.com>]

ok didn't know that, then it can be removed.



On 10/22/07, Matej Knopp <ma...@gmail.com> wrote:
>
> We already have such thing. It's called SimpleSynchronousPageStore and
> it uses one file per page all in request thread. So it's not optimized
> at all, but it can be good for development.
>
> -Matej
>
> On 10/22/07, Johan Compagner <jc...@gmail.com> wrote:
> > remove the current implementation
> > the thing martijn wants is easy to make for development mode. Then we do
> > everything just in the request no fancy stuff just a dump
> > But the current imlementation does to much, so we could introduce a
> > DevPageFileStore that just dumps the pages as a file (maybe seperate per
> > page if pages references pages but thats then all)
> >
> > johan
> >
> >
> > On 10/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > Did we come to a conclusion?
> > > https://issues.apache.org/jira/browse/WICKET-746 relies on this.
> > >
> > > Eelco
> > >
> > > On 10/2/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > i can fix it a bit, but what i am doing then is don't make it that
> > > > performant as it is now
> > > > I just make it a bit more threadsafe by doing a bit more stuff in
> the
> > > > request itself..
> > > > Then everything is getting a bit easier.
> > > >
> > > > But if we remove it, i don't do that extra work of course.
> > > >
> > > > johan
> > > >
> > > >
> > > > On 10/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > On 10/1/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > > > I don't think there's any harm in leaving it, the problem is
> that
> > > > > > there are known thread-synchronization issues and there is noone
> > > > > > willing to fix it :)
> > > > >
> > > > > Johan doesn't want to?! :-)
> > > > >
> > > > > I'm +0 for removing; we have a good alternative, but otoh, a patch
> > > > > might come in the future.
> > > > >
> > > > > Eelco
> > > > >
> > > >
> > >
> >
>

Re: Vote: Remove FilePageStore

[Matej Knopp <ma...@gmail.com>]

We already have such thing. It's called SimpleSynchronousPageStore and
it uses one file per page all in request thread. So it's not optimized
at all, but it can be good for development.

-Matej

On 10/22/07, Johan Compagner <jc...@gmail.com> wrote:
> remove the current implementation
> the thing martijn wants is easy to make for development mode. Then we do
> everything just in the request no fancy stuff just a dump
> But the current imlementation does to much, so we could introduce a
> DevPageFileStore that just dumps the pages as a file (maybe seperate per
> page if pages references pages but thats then all)
>
> johan
>
>
> On 10/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > Did we come to a conclusion?
> > https://issues.apache.org/jira/browse/WICKET-746 relies on this.
> >
> > Eelco
> >
> > On 10/2/07, Johan Compagner <jc...@gmail.com> wrote:
> > > i can fix it a bit, but what i am doing then is don't make it that
> > > performant as it is now
> > > I just make it a bit more threadsafe by doing a bit more stuff in the
> > > request itself..
> > > Then everything is getting a bit easier.
> > >
> > > But if we remove it, i don't do that extra work of course.
> > >
> > > johan
> > >
> > >
> > > On 10/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > On 10/1/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > > I don't think there's any harm in leaving it, the problem is that
> > > > > there are known thread-synchronization issues and there is noone
> > > > > willing to fix it :)
> > > >
> > > > Johan doesn't want to?! :-)
> > > >
> > > > I'm +0 for removing; we have a good alternative, but otoh, a patch
> > > > might come in the future.
> > > >
> > > > Eelco
> > > >
> > >
> >
>

Re: Vote: Remove FilePageStore

[Johan Compagner <jc...@gmail.com>]

remove the current implementation
the thing martijn wants is easy to make for development mode. Then we do
everything just in the request no fancy stuff just a dump
But the current imlementation does to much, so we could introduce a
DevPageFileStore that just dumps the pages as a file (maybe seperate per
page if pages references pages but thats then all)

johan


On 10/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Did we come to a conclusion?
> https://issues.apache.org/jira/browse/WICKET-746 relies on this.
>
> Eelco
>
> On 10/2/07, Johan Compagner <jc...@gmail.com> wrote:
> > i can fix it a bit, but what i am doing then is don't make it that
> > performant as it is now
> > I just make it a bit more threadsafe by doing a bit more stuff in the
> > request itself..
> > Then everything is getting a bit easier.
> >
> > But if we remove it, i don't do that extra work of course.
> >
> > johan
> >
> >
> > On 10/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > On 10/1/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > I don't think there's any harm in leaving it, the problem is that
> > > > there are known thread-synchronization issues and there is noone
> > > > willing to fix it :)
> > >
> > > Johan doesn't want to?! :-)
> > >
> > > I'm +0 for removing; we have a good alternative, but otoh, a patch
> > > might come in the future.
> > >
> > > Eelco
> > >
> >
>

Re: Vote: Remove FilePageStore

[Eelco Hillenius <ee...@gmail.com>]

Did we come to a conclusion?
https://issues.apache.org/jira/browse/WICKET-746 relies on this.

Eelco

On 10/2/07, Johan Compagner <jc...@gmail.com> wrote:
> i can fix it a bit, but what i am doing then is don't make it that
> performant as it is now
> I just make it a bit more threadsafe by doing a bit more stuff in the
> request itself..
> Then everything is getting a bit easier.
>
> But if we remove it, i don't do that extra work of course.
>
> johan
>
>
> On 10/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > On 10/1/07, Matej Knopp <ma...@gmail.com> wrote:
> > > I don't think there's any harm in leaving it, the problem is that
> > > there are known thread-synchronization issues and there is noone
> > > willing to fix it :)
> >
> > Johan doesn't want to?! :-)
> >
> > I'm +0 for removing; we have a good alternative, but otoh, a patch
> > might come in the future.
> >
> > Eelco
> >
>

Re: Vote: Remove FilePageStore

[Johan Compagner <jc...@gmail.com>]

i can fix it a bit, but what i am doing then is don't make it that
performant as it is now
I just make it a bit more threadsafe by doing a bit more stuff in the
request itself..
Then everything is getting a bit easier.

But if we remove it, i don't do that extra work of course.

johan


On 10/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 10/1/07, Matej Knopp <ma...@gmail.com> wrote:
> > I don't think there's any harm in leaving it, the problem is that
> > there are known thread-synchronization issues and there is noone
> > willing to fix it :)
>
> Johan doesn't want to?! :-)
>
> I'm +0 for removing; we have a good alternative, but otoh, a patch
> might come in the future.
>
> Eelco
>

Re: Vote: Remove FilePageStore

[Eelco Hillenius <ee...@gmail.com>]

On 10/1/07, Matej Knopp <ma...@gmail.com> wrote:
> I don't think there's any harm in leaving it, the problem is that
> there are known thread-synchronization issues and there is noone
> willing to fix it :)

Johan doesn't want to?! :-)

I'm +0 for removing; we have a good alternative, but otoh, a patch
might come in the future.

Eelco

Re: Vote: Remove FilePageStore

[Matej Knopp <ma...@gmail.com>]

I don't think there's any harm in leaving it, the problem is that
there are known thread-synchronization issues and there is noone
willing to fix it :)

-Matej

On 10/1/07, Al Maw <wi...@almaw.com> wrote:
> Matej Knopp wrote:
> > since we have DiskPageStore and it seems to work quite well and there
> > are known threading issues in FilePageStore which noone seems to want
> > to fix, I propose a vote to remove FilePageStore, as it no longer
> > seems to be necessary.
> >
> > Thus the options are:
> >
> > [  ]  Remove FilePageStore
> > [  ]  Keep FilePageStore, because I need it for <insert why> and
> > DiskPageStore doesn't cut it because <insert why>
>
> Does it do any harm leaving it in? DiskPageStore is relatively unproven,
> so we could always hedge our bets and leave it in there as an option for
> people for whom it works just fine, or in case someone has issues with
> DiskPageStore as an alternative. I don't really mind either way.
>
> Regards,
>
> Al
>

Re: Vote: Remove FilePageStore

[Al Maw <wi...@almaw.com>]

Matej Knopp wrote:
> since we have DiskPageStore and it seems to work quite well and there
> are known threading issues in FilePageStore which noone seems to want
> to fix, I propose a vote to remove FilePageStore, as it no longer
> seems to be necessary.
> 
> Thus the options are:
> 
> [  ]  Remove FilePageStore
> [  ]  Keep FilePageStore, because I need it for <insert why> and
> DiskPageStore doesn't cut it because <insert why>

Does it do any harm leaving it in? DiskPageStore is relatively unproven, 
so we could always hedge our bets and leave it in there as an option for 
people for whom it works just fine, or in case someone has issues with 
DiskPageStore as an alternative. I don't really mind either way.

Regards,

Al

Re: Vote: Remove FilePageStore

[Martijn Dashorst <ma...@gmail.com>]

Come to think of it, I think we didn't use the variant that uses a
separate thread for writing to disk. Ours is the 'in-process'
filestore. That might explain why we don't seem to experience
threading issues.

Martijn

On 9/30/07, Matej Knopp <ma...@gmail.com> wrote:
> Well, it has worked well for you. But there are people complaining
> about threading issues, which DiskPageStore doesn't have (doesn't
> there are no issues we don't know of yet :) )
>
> As for the command line utility, It's not possible as a separate
> process I'm affraid. You need window manager information which are for
> performance reasons only held in memory. But the DiskPageStore can be
> easily extended to retrieve portion of the file belonging to each
> page.
>
> -Matej
>
> On 9/30/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > +1
> >
> > Is it possible to create a command line utility that enables you to
> > browse a user's session with the DiskPageStore? It is quite easy to do
> > that with the FilePageStore.
> >
> > The FPS has run for about half a year (still is) in a production
> > system, so it is not *that* bad. But if the DPS is much better, then I
> > am all ears.
> >
> > Martijn
> >
> > On 9/30/07, Matej Knopp <ma...@gmail.com> wrote:
> > > Hi,
> > >
> > > since we have DiskPageStore and it seems to work quite well and there
> > > are known threading issues in FilePageStore which noone seems to want
> > > to fix, I propose a vote to remove FilePageStore, as it no longer
> > > seems to be necessary.
> > >
> > > Thus the options are:
> > >
> > > [  ]  Remove FilePageStore
> > > [  ]  Keep FilePageStore, because I need it for <insert why> and
> > > DiskPageStore doesn't cut it because <insert why>
> > >
> > > -Matej
> > >
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-beta3 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

Re: Vote: Remove FilePageStore

[Matej Knopp <ma...@gmail.com>]

Well, it has worked well for you. But there are people complaining
about threading issues, which DiskPageStore doesn't have (doesn't
there are no issues we don't know of yet :) )

As for the command line utility, It's not possible as a separate
process I'm affraid. You need window manager information which are for
performance reasons only held in memory. But the DiskPageStore can be
easily extended to retrieve portion of the file belonging to each
page.

-Matej

On 9/30/07, Martijn Dashorst <ma...@gmail.com> wrote:
> +1
>
> Is it possible to create a command line utility that enables you to
> browse a user's session with the DiskPageStore? It is quite easy to do
> that with the FilePageStore.
>
> The FPS has run for about half a year (still is) in a production
> system, so it is not *that* bad. But if the DPS is much better, then I
> am all ears.
>
> Martijn
>
> On 9/30/07, Matej Knopp <ma...@gmail.com> wrote:
> > Hi,
> >
> > since we have DiskPageStore and it seems to work quite well and there
> > are known threading issues in FilePageStore which noone seems to want
> > to fix, I propose a vote to remove FilePageStore, as it no longer
> > seems to be necessary.
> >
> > Thus the options are:
> >
> > [  ]  Remove FilePageStore
> > [  ]  Keep FilePageStore, because I need it for <insert why> and
> > DiskPageStore doesn't cut it because <insert why>
> >
> > -Matej
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>

Re: Vote: Remove FilePageStore

[Martijn Dashorst <ma...@gmail.com>]

+1

Is it possible to create a command line utility that enables you to
browse a user's session with the DiskPageStore? It is quite easy to do
that with the FilePageStore.

The FPS has run for about half a year (still is) in a production
system, so it is not *that* bad. But if the DPS is much better, then I
am all ears.

Martijn

On 9/30/07, Matej Knopp <ma...@gmail.com> wrote:
> Hi,
>
> since we have DiskPageStore and it seems to work quite well and there
> are known threading issues in FilePageStore which noone seems to want
> to fix, I propose a vote to remove FilePageStore, as it no longer
> seems to be necessary.
>
> Thus the options are:
>
> [  ]  Remove FilePageStore
> [  ]  Keep FilePageStore, because I need it for <insert why> and
> DiskPageStore doesn't cut it because <insert why>
>
> -Matej
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

Re: Vote: Remove FilePageStore

[Johan Compagner <jc...@gmail.com>]

remove it.

On 9/30/07, Matej Knopp <ma...@gmail.com> wrote:
>
> Hi,
>
> since we have DiskPageStore and it seems to work quite well and there
> are known threading issues in FilePageStore which noone seems to want
> to fix, I propose a vote to remove FilePageStore, as it no longer
> seems to be necessary.
>
> Thus the options are:
>
> [  ]  Remove FilePageStore
> [  ]  Keep FilePageStore, because I need it for <insert why> and
> DiskPageStore doesn't cut it because <insert why>
>
> -Matej
>