Smalltalk › Instantiations

Registering WASstServer adaptor "too late" irritates Apache

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

jtuchel

Registering WASstServer adaptor "too late" irritates Apache

Dear co-VAST users,

I am not sure if this is a bug report, a feature request, an experience report or a question...

I just found out that if a packaged image on Linux (ubuntu - haven't tested any other platform) doesn't register its WASstServer adapter very soon after image startup, it won't serve anything (tested with HTTP requests throuch Apache 2.4 and using curl from the local machine).
Mor details can be found in this blog post

I would like to understand why this happens and probably make this a bug report. Shouldn't it be completely irrelevant how late after image startup the WASstServerAdaptor is registered?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Seth Berman

Re: Registering WASstServer adaptor "too late" irritates Apache

Hello Joachim,

I don't have much experience in this area, so be patient as I try and understand.

I'm assuming something like mod_proxy is not caching the 503 or long periods of time...I'm guessing this because you said you used curl to verify there was no actual connection...as well as logging.
Your 'loadAllNecessaryStuff' is unyielding as far as you know? Have you tried wrapping it in a critical block. Can't offhand see why this would solve the problem..but it would be nice to establish the most sequential form of the lgoic possible.
I know it's a packaged image...so this logic is run when? On an actual startUp hook?
Is it possible to test this without Apache?
Its possible the actual timing issue is related to what happens between startSeasieAdaptorOnPort... and WAAdmin register...moving your loadAllNecessaryStuff may have simply masked this issue.
I emulated this in an open development image using a very long calculation in loadAllNecessaryStuff...and my best guess at startSeasideAdaptorOnPort: and this seemed to work no matter where I put loadAllNecessaryStuff...but probably has little to do with the actual issue since this is at startUp.

On Sunday, February 21, 2016 at 4:44:11 AM UTC-5, Joachim Tuchel wrote:

Dear co-VAST users,

I am not sure if this is a bug report, a feature request, an experience report or a question...

I just found out that if a packaged image on Linux (ubuntu - haven't tested any other platform) doesn't register its WASstServer adapter very soon after image startup, it won't serve anything (tested with HTTP requests throuch Apache 2.4 and using curl from the local machine).
Mor details can be found in this <a href="https://joachimtuchel.wordpress.com/2016/02/17/seaside-registering-a-waapplicaton-too-late-leads-to-an-http-503-error/" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fjoachimtuchel.wordpress.com%2F2016%2F02%2F17%2Fseaside-registering-a-waapplicaton-too-late-leads-to-an-http-503-error%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNGf_uoJGOJ37oAIcHWEwpBldP4McA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fjoachimtuchel.wordpress.com%2F2016%2F02%2F17%2Fseaside-registering-a-waapplicaton-too-late-leads-to-an-http-503-error%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNGf_uoJGOJ37oAIcHWEwpBldP4McA';return true;">blog post

I would like to understand why this happens and probably make this a bug report. Shouldn't it be completely irrelevant how late after image startup the WASstServerAdaptor is registered?

Joachim

jtuchel

Re: Registering WASstServer adaptor "too late" irritates Apache

Hi Seth,

first of all: thanks for asking back. I know my description may not contain all that's necessary to understand the problem.

Am Montag, 22. Februar 2016 19:01:45 UTC+1 schrieb Seth Berman:

Hello Joachim,

I don't have much experience in this area, so be patient as I try and understand.
I'm assuming something like mod_proxy is not caching the 503 or long periods of time...I'm guessing this because you said you used curl to verify there was no actual connection...as well as logging.

Exactly. I am quite sure we can even remove Apache from the equation, because curl from the host locally also gets no repsonse.
So I first thought this is an Apache related problem. But it isn't. At least that is what I derive from the fact that curl gets no response.

Your 'loadAllNecessaryStuff' is unyielding as far as you know? Have you tried wrapping it in a critical block. Can't offhand see why this would solve the problem..but it would be nice to establish the most sequential form of the lgoic possible.

With unyielding you mean it doesn't do something like Processor yield? In that case you are right. It is just a bunch of Glorp Queries that load lots of objects one after the other. I never thought about multiple threads or such for this case becaus this is the startup sequence of server and there is little to nothing useful it could do before it has loaded all that. The fact that users managed to log in during that time and produce walkbacks due to missing pre-load-data tells me there is no blocking going on, however. I share your scepticism about the critical block, but maybe it would at least keep people from logging in ;-)

I know it's a packaged image...so this logic is run when? On an actual startUp hook?

This is the very method that gets called by the ImageStartup code. The one that is defined in the PackagedImage Browser.

Is it possible to test this without Apache?

Sure. Like by using curl ;-)

Its possible the actual timing issue is related to what happens between startSeasieAdaptorOnPort... and WAAdmin register...moving your loadAllNecessaryStuff may have simply masked this issue.

Well, yes ;-)

I emulated this in an open development image using a very long calculation in loadAllNecessaryStuff...and my best guess at startSeasideAdaptorOnPort: and this seemed to work no matter where I put loadAllNecessaryStuff...but probably has little to do with the actual issue since this is at startUp.

The funny thing is that in a development image you can start/stop the WASstServerAdaptor all the time, and of course the Browser will get results once it is started, no matter how long the image has been running or the adapter has been stopped. So maybe we are really talking about some completely unrelated problem. I'll have to investigate a little further.

Joachim