GemServer and subclasses

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

GemServer and subclasses

BrunoBB
Hi All,

For development purpose my web app run with:
   | handler commitThreshold |
   commitThreshold := 65.
   handler := AlmostOutOfMemory addDefaultHandler: [ :ex | self halt ].
   SessionTemps current at: #'AlmostOutOfMemoryStaticException' put: handler.
   System signalAlmostOutOfMemoryThreshold: commitThreshold.
[WAGsZincAdaptor startOn: 8787]
  on: AlmostOutOfMemory enable
  do: [:ex | ex error: ex description].

For a production environment ....
The Adaptor class should be used directly or should i use a GemServer sublcass like ZnGemServer ?
(maybe my own sublcass of ZnGemServer  ??)

Right now i'm reading:
https://github.com/GsDevKit/gsApplicationTools/blob/master/docs/gettingStarted.md

regards
bruno
Reply | Threaded
Open this post in threaded view
|

Re: GemServer and subclasses

BrunoBB
Ok,

ZnSeasideGemServer register: 'bpm' on: #(8787 8888 8989).
(ZnSeasideGemServer gemServerNamed: 'bpm') startGems.

Is working ok !

regards
bruno
Reply | Threaded
Open this post in threaded view
|

Re: GemServer and subclasses

BrunoBB
Hi,

I think the method for Production server will be with this:
ZnSeasideGemServer register: 'bpm' on: #(8787 8888 8989).
(ZnSeasideGemServer gemServerNamed: 'bpm') startGems.
"of course exceptions handlers are missing :) "

WAAdmin is still used to register components ?
WAAdmin register: WAOrbeonBackofficeLogin asApplicationAt:'orbeonBackoffice'.

Or there are method in GemServer subclasses ? (i did not found anything)

regards
bruno
Reply | Threaded
Open this post in threaded view
|

Re: GemServer and subclasses

BrunoBB
Hi,

Which is the difference between ZnSeasideGemServer and ZnSeasideNewGemServer ?

regards,
bruno
Reply | Threaded
Open this post in threaded view
|

Re: GemServer and subclasses

GLASS mailing list
Bruno,

In the beginning there was WAGsZincAdaptor which was written to be very
similar in functionality to the FastCGI and Swazoo adaptors for
GemStone. WAGsZincAdaptor was to run against a pretty vanilla GemStone
port of Zinc which is to say that the basic structure of Zinc was
preserved. WAGsZincAdaptor as also intended to run using the
WAGemStoneRunSeasideGems class which is called from the
startSeaside30_adaptor script. This was all done around 2013.

In 2014 Sebastian Heidbrink began work on gsApplicationTools which was
intended to a create gem server framework for Zinc that supported all of
the Zinc services beyond Seaside, namely REST and WebSockets.  In late
2014, I forked Sebastian's work. At this point in time it became
necessary to do some work to adapt the Zinc servers for running in
GemStone: non-Seaside transaction support, object log-based logging,
interactive server debugging, improved error reporting..

This work ended with two new ZnServer subclasses:
ZnGemServerManagingMultiThreadedServer and
ZnTransactionSafeManagingMultiThreadedServer.

ZnGemServerManagingMultiThreadedServer was the original ZnServer class
designed to be used with GemServers and should work perfectly well with
Seaside

When working with REST and web sockets, transaction support is not
built-in as it is in Seaside and the
ZnTransactionSafeManagingMultiThreadedServer class was created to be
transaction safe ... the main difference between
ZnGemServerManagingMultiThreadedServer and
ZnTransactionSafeManagingMultiThreadedServer is that the socket
references in the ZnServer code are protected from being persisted
(GsSocket instances cannot be persisted).

A side-effect of making the ZnTransactionSafeManagingMultiThreadedServer
transactionally safe is that continuations can be safely snapped off for
error stacks in the ZnServer code itself --- a feature which can be
useful for Seaside applications as well.

So long story short, the ZnSeasideGemServer class works fine with
Seaside, but continuations cannot be used for the debugging ZnServer
errors. And continuations can be used to debug ZnServer errors with the
ZnSeasideNewGemServer class.

Dale

On 1/12/17 8:42 AM, BrunoBB via Glass wrote:

> Hi,
>
> Which is the difference between ZnSeasideGemServer and ZnSeasideNewGemServer
> ?
>
> regards,
> bruno
>
>
>
> --
> View this message in context: http://forum.world.st/GemServer-and-subclasses-tp4929474p4929486.html
> Sent from the GLASS mailing list archive at Nabble.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: GemServer and subclasses

GLASS mailing list
In reply to this post by BrunoBB


On 1/12/17 8:32 AM, BrunoBB via Glass wrote:

> Hi,
>
> I think the method for Production server will be with this:
> ZnSeasideGemServer register: 'bpm' on: #(8787 8888 8989).
> (ZnSeasideGemServer gemServerNamed: 'bpm') startGems.
> "of course exceptions handlers are missing :)"
>
> WAAdmin is still used to register components ?
> WAAdmin register: WAOrbeonBackofficeLogin
> asApplicationAt:'orbeonBackoffice'.
>
> Or there are method in GemServer subclasses ? (i did not found anything)
>
Nothing special needs to be done when registering components with
Seaside for GemServers ... The GemServer classes are used to manage the
http server for Seaside so other than the adaptors nothing must be done
differentls within Seaside itself.

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