Hi,
 I'm experiencing a nasty bug using sputnik on top of xavante. The bug is
really nasty since many factors contribute to it. I belive it has
something to do with the load_isolated_launcher in wsapi.common. 

It seems to try to reuse states to speedup the application loading
and if (app_state.mtime == mtime) no reload operation is performed.
Changing this test to fale (always call bootstra_app) solves the issue,
but I'm pretty sure It can not be that wrong thus I must be missing
something...

The bug is easy to reproduce on my setup, just edit a page (like the
configuration file) and change the main colour of sputnik... The
modification does not apply, repeatedly reloading the page gives
sometimes the expected result (the new color shows up) but not always,
while restarting xavante or touching sputnik.ws makes the modification
"stable". The bug is even nastries sometimes, since realoding may lead
the user to loose autentication (like if it was reusing a previous state 
in which the user had not log in yet...).

I've not tried sputnik on top of Apache, but I'll do soon to understand
if the problem is wsapi of wsapi+xavante/rings. Not sure it is
important, but I'm not using luarocks.require (but I'm using the very
same software that luarocks installed, I've just copied it in the right
path so that no luarocks.require is needed).

Any ideas?
-- 
Enrico Tassi

On Thu, Jul 17, 2008 at 2:47 PM, Enrico Tassi <gareuselesinge@libero.it> wrote:
> Hi,
>  I'm experiencing a nasty bug using sputnik on top of xavante. The bug is
> really nasty since many factors contribute to it. I belive it has
> something to do with the load_isolated_launcher in wsapi.common.
>
> It seems to try to reuse states to speedup the application loading
> and if (app_state.mtime == mtime) no reload operation is performed.
> Changing this test to fale (always call bootstra_app) solves the issue,
> but I'm pretty sure It can not be that wrong thus I must be missing
> something...
>
> The bug is easy to reproduce on my setup, just edit a page (like the
> configuration file) and change the main colour of sputnik... The
> modification does not apply, repeatedly reloading the page gives
> sometimes the expected result (the new color shows up) but not always,
> while restarting xavante or touching sputnik.ws makes the modification
> "stable". The bug is even nastries sometimes, since realoding may lead
> the user to loose autentication (like if it was reusing a previous state
> in which the user had not log in yet...).
>
> I've not tried sputnik on top of Apache, but I'll do soon to understand
> if the problem is wsapi of wsapi+xavante/rings. Not sure it is
> important, but I'm not using luarocks.require (but I'm using the very
> same software that luarocks installed, I've just copied it in the right
> path so that no luarocks.require is needed).

There is a flag that can be set in the xavante handler that allows you
to bypass this caching.  In xavante/config.lua you can change the
following line:

    { -- wsapihandler example
      match = {"%.ws$", "%.ws/" },
      with = wsapi.xavante.makeGenericHandler (webDir)
    },

to

    { -- wsapihandler example
      match = {"%.ws$", "%.ws/" },
      with = wsapi.xavante.makeGenericHandler (webDir, true)
    },

This was added by Fabio specifically for this reason [1].

Cheers!

[1]: http://lists.luaforge.net/pipermail/kepler-project/2008-April/002515.html

On Fri, Jul 18, 2008 at 10:52:58AM +0100, Jim Whitehead II wrote:
> On Thu, Jul 17, 2008 at 2:47 PM, Enrico Tassi <gareuselesinge@libero.it> wrote:
>       with = wsapi.xavante.makeGenericHandler (webDir, true)

Thank you very much!

may I add this to http://sputnik.freewisdom.org/en/Troubleshooting ?

Cheers
-- 
Enrico Tassi

Yes, please do for now, but this seems like an issue for which we'll
need an actual solution.  Should the installation script just override
xavante/config.lua?  The problem of course is also that Kepler rocks
tend to change, so this would introduce fragility without some
rock-control.  I am guessing the solution for this would be to go back
to the installation method I used with experimental "on the rocks"
installer in the spring, which was to run the kepler installer with
"--without-kepler", then install the necessary rocks with
"--only-from=http://sputnik...." flag.

But if we go this route, it would be good to figure out what's the
minimum set of rocks that we need for this.  I.e., I don't want to run
kepler installer with --without-kepler and then do "install kepler",
thus having to worry about maintaining up to date copies of cgilua,
orbit.  It's also an opportunity to cut down the size of the
installation.

The good news is that for CGI it's all quite trivial:

    bash kepler-install-1.1-1 --prefix=$SPUTNIK --without-readline
--without-kepler
    ./bin/luarocks install wsapi  # this just installs one rock
    ./bin/luarocks --from=http://sputnik.freewisdom.org/rocks/earth
install sputnik

Then create the sputnik.cgi file, etc. just like the current installer does.

To get rid of the second line and to switch to --only-from, I will
need to add seven rocks to my repository: cosmo, lbase64, lpeg,
luafilesystem, markdown, md5, luasocket.

"./bin/luarocks install xavante" then requires "copas", "coxpcall"
This doesn't give us a way of actually starting Xavante.  It looks
like we are just missing a few files, though, so perhaps it would make
sense to hack together a sputnik-xavante rock with those files and a
dependency on xavante?

This somewhat more complicated installation method saves us five rocks
(cgilua, orbit, rings, kepler and kepler-xavante) and halves the total
size of the installation.  (Orbit accounts for about 1/2 of the
current installation - 2.3 MB out of 5.1.  Without
orbit/kepler/cgilua/etc we are down to 2.4MB)

  - yuri


On Fri, Jul 18, 2008 at 5:25 AM, Enrico Tassi <gareuselesinge@libero.it> wrote:
> On Fri, Jul 18, 2008 at 10:52:58AM +0100, Jim Whitehead II wrote:
>> On Thu, Jul 17, 2008 at 2:47 PM, Enrico Tassi <gareuselesinge@libero.it> wrote:
>>       with = wsapi.xavante.makeGenericHandler (webDir, true)
>
> Thank you very much!
>
> may I add this to http://sputnik.freewisdom.org/en/Troubleshooting ?
>
> Cheers
> --
> Enrico Tassi
>
> _______________________________________________
> Sputnik-list mailing list
> Sputnik-list@lists.luaforge.net
> http://lists.luaforge.net/cgi-bin/mailman/listinfo/sputnik-list
>



-- 
http://sputnik.freewisdom.org/