[daisy] [JIRA] Commented: (DSY-431) Daisy wiki wrapper script should check/wait 'smart' for the repository to run!

[Marc Portier (JIRA)]

    [ http://issues.cocoondev.org//browse/DSY-431?page=comments#action_13093 ] 

Marc Portier commented on DSY-431:
----------------------------------

Extra comments from the mailinglist:


----------------------------------------------------------------------------------------------
[1]  http://lists.cocoondev.org/pipermail/daisy/2007-March/006080.html

<< Scott using a feature of the wrapper script

I had a similar problem on Windows Machines there is a setting in the
Wrapper file that causes the wiki to delay for 30 seconds (I think it's
seconds)

	wrapper.startup.delay=30

Hope this helps.

I am not sure if this will work on linux as well? I would only assume it
would. 

(marc checked: it does, as expected)
----------------------------------------------------------------------------------------------
[2] http://lists.cocoondev.org/pipermail/daisy/2007-March/006078.html
[3] http://lists.cocoondev.org/pipermail/daisy/2007-March/006081.html

<< Steven and Andreas providing versions for windows, mac osx and solaris

----------------------------------------------------------------------------------------------
[4] http://lists.cocoondev.org/pipermail/daisy/2007-March/006087.html
[5] http://lists.cocoondev.org/pipermail/daisy/2007-March/006156.html

<< Bruno adding insight:

A possible solution would be to do the initialization in a background
thread, which could retry to connect until it succeeds. This way,
initialization of cocoon will not fail, a nicer error can be shown if
the connnection was not yet established, and it copes with the wiki
being up earlier than the repo.

<< and later self-reflection:

I've given this some more thought and came to the conclusion that the
solution I was thinking of wasn't so simple after all. It's not only the
initialization of the RemoteRepositoryManager which needs to be delayed,
but also of all components depending on it (in the Wiki e.g. the user
registrar) and of the JMS component.

So it would rather have to be the initialization of Cocoon as a whole
which needs to be delayed. Or components depending on the
RemoteRepositoryManager should be designed to initialize only upon first
request. Not sure if this is a good idea though.

For now, it seems delaying the startup of the servlet container until
the repository server is running is the best solution.


> Daisy wiki wrapper script should check/wait 'smart' for the repository to run!
> ------------------------------------------------------------------------------
>
>          Key: DSY-431
>          URL: http://issues.cocoondev.org//browse/DSY-431
>      Project: Daisy
>         Type: Improvement
>     Reporter: Marc Portier
>     Priority: Minor

>
> Now that we have the wrapper scripts packaged in the distro I can assume people are going to be hooking them up easily as init.d start-stop scripts on their linux distro (or as services on windows)
> However, on linux I've seen this cause the wiki to start up before the repo is actually running and thus make the wiki initialize badly (typical symptom is a cocoon error page talking about an initialization error)
> In our experimental debian package we already have scripts with a trick for this (see below)
> Before hacking this in as a patch for the shell scripts, I'ld like to learn if Windows services have similar issues, and if we could find a common solution?
> wait_for_server_start () {
>   port=$1
>   counter=0
>   serverstatus=`netstat -l  | grep -e "^tcp.*:${port}"`
>   while [[ -z "${serverstatus}" &&  ${counter} -lt 12 ]]; do
>     sleep 2s
>     serverstatus=`netstat -l  | grep -e "^tcp.*:${port}"`
>     let counter=counter+1
>   done
>   if [ -z "${serverstatus}" ]; then
>     echo Not listening to port $port .  Exiting ...
>     exit 1
>   else
>     echo Listening to port $port
>   fi
> }
> + call this wait...() function from the start() 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira