Hi Bob,
The variable name is bit misleading. gen_server:cast is very happy
with atoms and Pids as well. As long as the atom is the name a process
is registered under. In this case this is true as the couch_log
process is registered under the name couch_log.
Well I'm not very familiar with the code yet but as far as I can see
this will never work or rather it will always work, but will not do
anything:
1. couch_log (which is a gen_event) stop function calls
couch_event_sup:stop(couch_log)
2. couch_event_sup:stop/1 call gen_server:cast(couch_log,stop)
The problem is on two levels:
1. couch_log is a gen_event not a gen_server. This might actually work
though meaning that the couch_log will get the stop message on the
handle_info/2 function (note: the gen_event does not have a
handle_cast callback). Otherwise the message will just go to the void.
It is probably the first.
2. couch_log does not have code to handle the stop message.
Not to mention it does not make sense imho to jump back to the
couch_event_sup to restart oneself. By the way why is the
couch_event_sup a gen_server not a supervisor?
Wouldn't having a supervisor (couch_event_sup) which would restart the
gen_event if it stops itself work better?
... I've read a bit more of the code (still wrapping my head around
the whole codebase): The couch_event_sup is not even related to the
couch_log so why is couch_log calling into it?
Did I read the whole thing wrong?
Regards,
Tamas
Tamas Nagy
Erlang Training & Consulting
http://www.erlang-consulting.com
On 30 Jun 2009, at 13:03, Robert Dionne wrote:
On Jun 29, 2009, at 4:42 PM, Adam Kocoloski (JIRA) wrote:
[ https://issues.apache.org/jira/browse/COUCHDB-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725336
#action_12725336 ]
Adam Kocoloski commented on COUCHDB-397:
----------------------------------------
Hi Paul, I probably shouldn't have brought up the whole
exit(couch_config, blah) thing. Let's focus on the supervisor
behavior.
The trunk code *does not* restart any secondary services. AFAICT
these lines are a no-op:
supervisor:terminate_child(couch_secondary_services, couch_server),
supervisor:restart_child(couch_secondary_services, couch_server).
There is no child of couch_secondary_services named couch_server.
Damien should comment on the rationale. Perhaps what was intended
was
supervisor:terminate_child(couch_server_sup,
couch_secondary_services),
supervisor:restart_child(couch_server_sup,
couch_secondary_services).
That change would also fix COUCHDB-398 -- it just restarts a bit
more of the application than what I posted.
Not sure where I made a comment that indicated my diff in
COUCHDB-398 didn't work. I've checked -- it does reset the stats
counters, and the test suite does pass.
I think having a working _restart handler would actually be kinda
useful, much like the _log handler Jan implemented a while back.
Adam,
Thanks for finding this stats bug, I've been randomly seeing it for
some time and it was annoying. Actually I was just reviewing
couch_log, in light of your comments in COUCHDB-355 about
couch_db_update_notifier_sup. It should do a similar thing to
couch_log when the config changes and an empty value is set, stop
the module and let it restart.
However looking at couch_log I'm not sure if the stop function
works correctly as it calls couch_event_sup:stop(couch_log), passing
an atom, where the couch_event_sup function wants a Pid. Seems odd?
Cheers,
Bob
I propose that /_restart should gracefully restart the entire couch
application, not just the couch_server process. Cheers, Adam
POST _restart only restarts couch_server process
------------------------------------------------
Key: COUCHDB-397
URL: https://issues.apache.org/jira/browse/COUCHDB-397
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.9
Reporter: Adam Kocoloski
Assignee: Adam Kocoloski
Perhaps this is by design, but POSTing to /_restart only restarts
the couch_server process. It does not restart any of the other
myriad processes CouchDB relies on for operation. In particular,
this causes the stats test suite to occasionally fail, because the
stats counters do not get reset. The test that fails is
Assertion 'open_databases > 0 && max >= open_databases, name'
failed: should keep the same number of open databases when
reaching the max_dbs_open limit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
