[Glass] loading seaside and zinc

[Mariano Martinez Peck]

On Thu, Dec 5, 2013 at 7:20 PM, Dale K. Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Mariano,
>
> It's been awhile since I worked on the WAGemStoneRunSeasideGems class, but
> I see that you are expecting both Swazoo and FastCGI gems to be running
> concurrently and I don't think that class was designed for such a use case
> ...
>
> From what I recall, it's an either/or type of setup where you manage a set
> of FastCGI gems _or_ a set of Swazoo gems not both, so I guess I'm not
> surprised that things aren't quite working correctly ...
>
>
OK, yes, I have the same thoughts. Ok, I will see if I can refactor it a
bit to make it work.
My usecase is this: I use FastCGI for real, I have nginx as frontend and
doing the upstream to GemStone. That is under HTTPS managed by nginx and
that the open port from the outside.
 But sometimes, I want to debug if there is a problem in the nginx
configuration or in fastCGI etc... So I want to also be running a Swazoo in
a port (not opened in the firewall) so that then I can ssh and tunnel it
from my machine to test it.


> BTW, my read of that script would leave a swazoo gem running, but
> unmanaged (i.e., once you switched to the WAFastCGIAdaptor,
> WAGemStoneRunSeasideGems forgets about the WAGsSwazooAdaptor) ...
>
> With tODE I plan to change the way that Seaside gems are managed ...
> something along the lines of the SeasideBrowser(?) for Pharo...
>
>
SeasideBrowser? what's that?


> Dale
>
>
> ------------------------------
>
> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
> *To: *"Johan Brichau" <johan at yesplan.be>
> *Cc: *glass at lists.gemtalksystems.com
> *Sent: *Thursday, December 5, 2013 5:55:52 AM
>
> *Subject: *Re: [Glass] loading seaside and zinc
>
>
>
>
> On Sat, Nov 16, 2013 at 6:54 AM, Johan Brichau <johan at yesplan.be> wrote:
>
>>
>> On 16 Nov 2013, at 00:07, Mariano Martinez Peck <marianopeck at gmail.com>
>> wrote:
>>
>> > BTW...with your magic lines to start Swazoo...that doens't block!! It
>> works perfect. Why it doesn't block that one while Zinc does?  It open
>> another gem or something?
>>
>> No magic and not mine :-) Just gemstone multi-vm.
>> So yes, it actually invokes the command-line scripts that start other
>> topaz processes where the blocking call to the adaptor happens.
>> You can take a look at the startSeaside30Adaptor script in the
>> $gemstone/product/seaside/bin directory
>>
>
>
> OK. I took a look to the scripts and I still don't understand why the
> following code doesn't work. I am trying to run 3 gems for FastCGI and 1
> gem for swazoo, both none blocking (that is, I want to open separate gems
> for them):
>
> WAGemStoneRunSeasideGems default
>         name: 'Swazoo';
>         adaptorClass: WAGsSwazooAdaptor;
>         ports: #(5858).
> WAGemStoneRunSeasideGems restartGems.
>
>
> WAFastCGIAdaptor stop.
> WAGemStoneRunSeasideGems default
>         name: 'FastCGI';
>         adaptorClass: WAFastCGIAdaptor;
>         ports: #(9001 9002 9003).
> WAGemStoneRunSeasideGems restartGems.
>
>
> At the end, I either get 4 gems all with FastCGI or all with Swazoo. What
> I don't get is that I change the default instance information, so I don't
> get why the second #restartGems would affect the first one.
>
> Log is
>
>
> ---restart Seaside gems (12/05/2013 05:49:55)
> Restarting Gems...
> Stopping Gems...
>    Stopping Swazoo topaz PID 72543 running on port 5858
>    Stopping maintenance gem PID 72544
> Starting Gems....
> Starting Swazoo gem on port 5858
> Starting maintenance gem
>
> ---Finished Seaside gems restart (12/05/2013 05:49:58)
> ---restart Seaside gems (12/05/2013 05:49:58)
> Restarting Gems...
> Stopping Gems...
>    Stopping FastCGI topaz PID 72523 running on port 9001
>    Stopping FastCGI topaz PID 72525 running on port 9002
>    Stopping FastCGI topaz PID 72527 running on port 9003
>    Stopping maintenance gem PID 72567
> Starting Gems....
> Starting FastCGI gem on port 9001
>  Starting FastCGI gem on port 9002
> Starting FastCGI gem on port 9003
> Starting maintenance gem
>
> ---Finished Seaside gems restart (12/05/2013 05:50:00)
>
>
> Thanks!
>
>
>
>> >  Ok, cool. In the meanwhile I continue using Swazoo that for my current
>> needs (start porting) works fine.
>> > If there is anything I could do/test, let me know!
>>
>> When an error is raised inside the app, the adaptor indeed crashes.
>> The funny thing is that the handleRequest: method returns a WAResponse
>> class instead of an instance. I have to digg deeper to understand where
>> that happens but it is the same error that I got before removing the
>> #requestFor: method. It seems that an error occurs deeper in the code that
>> is handled and then the WAResponse class is returned as a value...
>>
>> Johan
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131206/97cc68ab/attachment.html>