plugins.Monitor instances not activated under mod_wsgi?

[Ralph Heinkel]

Hi everybody,

I've implemented two plugins.Monitor classes in my cp server, both
function as expected when running under the internal cherrypy http
server. However those threads created by the Monitor class instances
seem like not being started when the server runs in apache under
mod_wsgi. Is there a reason why? Do I need to manually call the
start() method on them?

Any advice would be great.

Thanks

Ralph

[Sylvain Hellegouarch]

Hi Ralph,

Are you calling cherrypy.engine.start()? If not, please do so :) 

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

[Ralph Heinkel]

Hello Sylvain,

thanks for your reply.
I think I got misled by the documentation at http://tools.cherrypy.org/wiki/ModWSGI which says that "CherryPy 3.1 supports running CherryPy applications as WSGI applications without requiring the internal CherryPy engine be run manually, so for that and later versions the lines [...] cherrypy.engine.start() [...] are not required."
It doesn't mention that some cherrypy features like Monitors would not work with that omission.

But I give it a try using engine.start().

ciao ciao

Ralph

--
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To post to this group, send email to cherryp...@googlegroups.com.
To unsubscribe from this group, send email to cherrypy-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cherrypy-users?hl=en.

[Ralph Heinkel]

On 07.08.12 18:11, Sylvain Hellegouarch wrote:

Hi Ralph,

On Tue, Aug 7, 2012 at 4:32 PM, Ralph Heinkel <ralph....@web.de> wrote:

Hi everybody,

I've implemented two plugins.Monitor classes in my cp server, both function as expected when running under the internal cherrypy http server. However those threads created by the Monitor class instances seem like not being started when the server runs in apache under mod_wsgi. Is there a reason why? Do I need to manually call the start() method on them?

Any advice would be great.

Are you calling cherrypy.engine.start()? If not, please do so :) 

Hmm, this tries to connect the cherrypy engine to port 8080 ... is that the desired behavior when running within mod_wsgi? All I really need is that Monitors are started.

Ralph

[Robert Brewer]

Ralph Heinkel wrote:
> Hmm, this tries to connect the cherrypy engine to port 8080 ...
> is that the desired behavior when running within mod_wsgi?
> All I really need is that Monitors are started.

If you're using mod_wsgi, turn off the default HTTP server via:

cherrypy.server.unsubscribe()

...before you call engine.start.


Robert Brewer
fuma...@aminus.org

[Sylvain Hellegouarch]

Yeap, went too fast earlier on. Starting the engine will start all its registered plugins, which means the default HTTP server. Unsubscribe it beforehand as Robert explains and this won't happen :)

 

I'll admit, I've never worked with mod_wsgi so I may be wrong when suggesting starting the engine.

[Ralph Heinkel]

yes, thanks, cherrypy.server.unsubscribe() really did the job!

ciao ciao

Ralph

[Rogier van der Wel]

I am facing a similar problem, and was wondering if it matter exactly where I would call the  cherrypy.server.unsubscribe() and cherrypy.engine.start() functions. 

1 -  Should I be calling these methods from my wsgi start script or from my application sources?

2 - Should I keep the logic of comparing to current engine state first?

3 -  Shouldn't the engine state be compared to an object named like (cherrypy.process.wspbus.)states.STOPPED instead of a zero?

//Rogier