[Glass] Fwd: loading seaside and zinc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] loading seaside and zinc

Johan Brichau-3

On 16 Nov 2013, at 10:54, Johan Brichau <[hidden email]> wrote:

> 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...

I put up a new version of the package containing the bugfixes on seaside.gemtalksystems.com/ss/Seaside30

Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] loading seaside and zinc

Mariano Martinez Peck
In reply to this post by Johan Brichau-3



On Sat, Nov 16, 2013 at 6:54 AM, Johan Brichau <[hidden email]> wrote:

On 16 Nov 2013, at 00:07, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] loading seaside and zinc

Dale Henrichs-3
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 ...

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...

Dale



From: "Mariano Martinez Peck" <[hidden email]>
To: "Johan Brichau" <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> wrote:

On 16 Nov 2013, at 00:07, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] loading seaside and zinc

Mariano Martinez Peck



On Thu, Dec 5, 2013 at 7:20 PM, Dale K. Henrichs <[hidden email]> 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" <[hidden email]>
To: "Johan Brichau" <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> wrote:

On 16 Nov 2013, at 00:07, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] loading seaside and zinc

Dale Henrichs-3



From: "Mariano Martinez Peck" <[hidden email]>
To: "Dale K. Henrichs" <[hidden email]>
Cc: [hidden email], "Johan Brichau" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
To: "Johan Brichau" <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> wrote:

On 16 Nov 2013, at 00:07, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
Mariano
http://marianopeck.wordpress.com


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
12