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 [email protected].
>>> To post to this group, send email to [email protected].
>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
