Re: [Mojolicious] Singleton(s) and workers

[Boris Baldassari]

Hi all,

I finally got it working using File::ChangeNofity instead of 
AnyEvent::Filesys::Notify, since it needs less dependencies and is good 
enough for my needs. The idea of watching file changes was a really good 
one, thanks again to Jan.

I still have one question to finish that: how could I test the 
thread-safe behaviour? When running the tests (e.g. with myapp.pl test) 
I make the assumption that Mojolicious is using something like morbo, 
that is a single-threaded version of the application. Is there any means 
to either:
* test the app in a preforked context (by launching hypno or prefork 
server instead of a dev one)
* tell the test run to use an existing web site instead of the current dev?

The last option would be the best, since it would really test the app in 
a production context. But I could not find anywhere a way to tell the 
test agent to look for a specific url (where my dev is hosted)... Is 
there one?

Thanks,

--
Boris



Le 23/10/2015 21:10, Boris Baldassari a écrit :
Le 23/10/2015 12:22, Jan Henning Thorsen a écrit :
If it's not critical that changes in the file is visible instantly, you
could do something like this:
It's not critical if the changes appears after a few seconds, so the 
idea is good, thank you -- and thanks for the code, which is helpful.


This will make the application read the file every 30 second and update
the "dashboard" config parameter. The code could also check if the
timestamp of the json file has changed and simply not read the content
if mtime is the same.
I didn't like the idea of checking a mtime each time I did a request 
to the data -- which would be almost each time a user displays a page. 
Feels like loosing the efficiency of having everything in memory.

Another idea is to use AnyEvent::Filesys::Notify instead of the
recurring timer. (There might be similar solutions, but that was the one
that came to mind first)
Oh, I didn't know of that one. And really like it, for it respects the 
data/file paradigm for understandability.
It may indeed be the best solution, among other things for 
portability. I will give it a try, and report back to the list next week.
Really good advice, thanks!


About hot reloading: If you are running both the workers and manager as
the same user, then the worker can do initiate hot reload using "kill
USR2 => getppid".
Yes, smart! Still GTK (Good To Know (tm)).

Thanks again,


--
Boris



On Friday, October 23, 2015 at 10:10:46 AM UTC+2, Boris Baldassari 
wrote:

    Hi Jan,

    The app is a kind of dashboard for sw project assessment, and it
    maintains a set of data on software projects (metrics,
    meta-information, etc.). There is an analysis (i.e. an update on
    this data) started every day, plus occasional changes on user's
    initiative. So the information is not changing *heavily*.

    My point is I *want* to maintain the data on disk as json files,
    because I believe that a data-based process (i.e. having a process
    transforming data between known states) is easier to read and
    understand for users and maintainers.
    After giving some thoughts to memcache/redis/etc. I realise I would
    have to synchronise the data on disk every time it changes, which is
    quite cumbersome and not very reliable.

    Maybe hot reloading hypnotoad would be the way to go. How could I do
    that from the code itself, apart from executing shell commands?

    Another option would be to load the data at startup, and write it
    down to the disk on shutdown (through a END sub). Not sure about the
    reliability of such a solution though.

    Any idea would be welcome. Thanks!

    --
    Boris



    Le jeudi 22 octobre 2015 12:52:07 UTC+2, Jan Henning Thorsen a 
écrit :

        Could you give some more details/examples on what kind of
        information that is changed during run? Also, how often does
        this information change?

        Reason for asking, is that you might come up with a far too
        complicated solution for this.

        In some cases, it would be enough to just change the config file
        and then hot reload hypnotoad, but this won't work if you're
        changing the config too often. On the other hand, reading data
        from memcache/redis/something is probably a better idea than
        trying to synchronise information internally between your 
workers.


        On Wednesday, October 21, 2015 at 12:16:51 PM UTC+2, Boris
        Baldassari wrote:

            Hi Ben,

            Thank you for the quick and to-the-point answer. I guess it
            won't work either with prefork instead of hypnotoad.

            I'll have a look at memcache and redis solutions.

            Thanks again -- I've spent some time on this, so it's good
            to have a confirmation/statement to settle the point.

            Have a great day!

            --
            boris



            Le mercredi 21 octobre 2015 11:14:42 UTC+2, Ben van Staveren
            a écrit :

                That won't work - under Hypnotoad every worker would end
                up with it's own copy, and while you would be able to
                update values inside a single worker, it wouldn't work
                across the entire worker pool. Consider using memcache
                or another key/value store that's convenient (redis,
                perhaps) to store information like that, and fetch it
                when required.


                On 10/21/2015 11:10 AM, Boris Baldassari wrote:
                Hiho dear Mojo folks,

                This is my first post here, so I'd like to start with
                a big thank you all for the work put on mojolicious.
                It just rocks. :-)

                I am building a full (not light) app which needs
                access to a set of variables (say config) stored in a
                dedicated module (MyApp::Model::Config). These values
                do change during the run, and I want all the workers
                to access the new values. This works very well in
                morbo, but as soon as I start using hypnotoad the
                values are not updated for all workers. As a
                consequence, depending on the worker serving your
                request you get either old or new values randomly.

                I started with a singleton helper put directly in the
                startup method:
                |
                $app->helper(repo =>sub{state $config
                =MyApp::Model::Config->new($app)});
                |
                This doesn't resolve the issue.

                Then I read about similar problems with db connection
                handles, and I decided to move them out of the startup
                method and I added some has attributes, still in the
                MyApp.pl class:
                |
                has my_config =>sub{state $config
                =MyApp::Model::Config->new($app);};
                |
                But it still doesn't work.

                So, how should I do that? Any advice on the design or
                code itself is welcome...

                Thanks in advance,

                --
                Boris
                --
                You received this message because you are subscribed
                to the Google Groups "Mojolicious" group.
                To unsubscribe from this group and stop receiving
                emails from it, send an email to
                mojolicious...@googlegroups.com.
                To post to this group, send email to
                mojol...@googlegroups.com.
                Visit this group at
                http://groups.google.com/group/mojolicious
<http://groups.google.com/group/mojolicious>.
                For more options, visit
                https://groups.google.com/d/optout
                <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to a topic in the
Google Groups "Mojolicious" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/mojolicious/T9uH9a14CHM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
mojolicious+unsubscr...@googlegroups.com
<mailto:mojolicious+unsubscr...@googlegroups.com>.
To post to this group, send email to mojolicious@googlegroups.com
<mailto:mojolicious@googlegroups.com>.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.