[Cppcms-users] reloading skins

[Marcel H. <ke...@co...>]

 

I hope this will will not be ugly tu read. A lot of code may be
inside of this. So hold on (: 

Hi everyone, 

first: congrats for v1.0
artyom. You still haven't announced it, but svn already knows it :)
It
is such a great framework. I never want to miss it and never go back to
PHP or similar. 

Now my request. 

I am not happy with the solution of
the auto reload skin function atm. As I mentioned long long time ago,
I'd like to control it over Signals, and that's why I searched in your
code and found this: 

src/service.cpp:366 

void handler(int
/*nothing*/)
{
 if(the_service)
 the_service->shutdown();
}

so I
changed it a bit and now it looks like this:

void handler(int sig)
{

BOOSTER_DEBUG("cppcms") << "Signal " << sig << " received.";
 if
(the_service)
 switch (sig) {
 case 10:
the_service->views_pool().reloadSkins(); break;
 default:
the_service->shutdown();
 }

}

signal 10 is, aymk, the USR1 sig and if
you send that sig to the prog, it should reload all the skins, no matter
if they are outdated or not.
So I changed:

cppcms/views_pool.h:192
(reloadSkins() is public)
 ///
 /// Reload the Skins, when they are
loaded via library.
 ///
 void reloadSkins();

and
also
src/views_pool.cpp:336
 // reload all if needed
 reloadSkins();

pool::instance().render(skin_name,template_name,out,content); //as far
as I see, render don't need a mutex lock
 return;
......

void
manager::reloadSkins()
{

booster::unique_lock<booster::recursive_shared_mutex> lock(d->lock);

for(size_t i=0;i<d->skins.size();i++) {
 impl::skin &current =
d->skins[i];
 time_t mtime = impl::get_mtime(current.file_name);
 //skip
time checking
 BOOSTER_DEBUG("cppcms") << "Reloading shared object/dll "
<< current.file_name;
 current.so.reset();
 current.mtime = mtime;

current.so.reset(new impl::shared_object(current.file_name,true));
 }

return;
}

What I did is to outsource the whole block, what is now
inside of reloadSkins(), nothing more. Now the signal handler can access
the method.

Next step was to build cppcms again and run the
messageboard example. I edited the config.js a bit, namely:
added
"auto_reload" to views (just for testing) and changed the logging level
to debug.

Make the example will run, and work as expected.
Now, to my
changes.
Here is the output:

2012-02-23 15:20:43; cppcms_http, info:
GET / (http_api.cpp:251)
2012-02-23 15:20:43; cppcms_http, info: GET
/media/style.css (http_api.cpp:251)
2012-02-23 15:20:43; cppcms_http,
info: GET /media/style-ltr.css (http_api.cpp:251)
 now editing the
template and compile it again, without restarting the prog
2012-02-23
15:21:23; cppcms_http, info: GET / (http_api.cpp:251)
2012-02-23
15:21:23; cppcms_http, info: GET /media/style.css
(http_api.cpp:251)
2012-02-23 15:21:23; cppcms_http, info: GET
/media/style-ltr.css (http_api.cpp:251)
 nothing happens, as you see.
Now the signal
2012-02-23 15:21:45; cppcms, debug: Signal 10 received.
(service.cpp:368)
2012-02-23 15:21:45; cppcms, debug: Reloading shared
object/dll .//libsimple.so (views_pool.cpp:351)
 Arrived and
reloaded
2012-02-23 15:21:55; cppcms_http, info: GET /
(http_api.cpp:251)
2012-02-23 15:21:55; cppcms_http, info: GET
/media/style.css (http_api.cpp:251)
2012-02-23 15:21:55; cppcms_http,
info: GET /media/style-ltr.css (http_api.cpp:251)
 but still there isn't
any change

Okay I thought, it is my fault and checked out the svn repo
again and build the example again, but still there is the same error.
So
whats next. I started to figure out, if the prog really uses the library
I override.
lsof examples/message_board/build/libsimple.so

 Output
information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF
NODE NAME
mb 11567 xxx mem REG 8,6 154864 5636786
./examples/message_board/build/libsimple.so

so yes, it loads the right
library and uses it. And I checked it twice, that the time of the
library is newer than the date of the program so that he should reload
the lib.

So two major things:
 - I think your implementation of the
time checking is invalid (it should load it before I'll give him the
signal
 - there is a huge mistake anywhere, so that he does not reload
the skin and print that out. Maybe a caching error?

When I wrote the
last sentence I had an idea and tried to prove that. And bäm, I was
right.
 It was an "error" with the caching mechanism. I would suggest,
that if you reload the skins, the whole cache should be reset. 

I'd
like you (artyom) to implement the following into cppcms with cache
resetting, of cource. Oh and don't forget my "patch" ticket in
sourceforge. (just two missing whitespaces) 

Regards

Marcel Hellwig