[Glass] loading seaside and zinc

[Dale K. Henrichs]

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| Cc: glass at lists.gemtalksystems.com, "Johan Brichau"
| <johan at yesplan.be>
| Sent: Friday, December 6, 2013 6:14:35 AM
| Subject: Re: [Glass] loading seaside and zinc

| 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.
I do the same thing for ss3 (or used to at any rate) and it's pretty easy to write a shell script that stops/starts the 4 seaside gems that you want ... and in production you'll want a script like this anyway ... and you can use System class>>performOnServer: to run the script ... 

| | 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?
I'm referring to the control panel that was written in OmniBrowser to manage your adaptors ... you could start/stop different sets of adaptors from the gui ... instead of executing chunks of code in a workspace ... 

| | 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/5135c05f/attachment-0001.html>