Instructions to start zinc gs adaptor

I'm trying to start to WAGsZincAdaptor in gemstone 2.4.4.1 Does anybody have detailed instructions how to achieve this. The snippets I found on the web aren't working.
If I try

WAGemStoneRunSeasideGems default
  name: 'Zinc';
  adaptorClass: WAGsZincAdaptor;
  ports: #(8000);
  yourself.
WAGemStoneRunSeasideGems restartGems

I see messages in the transcript telling me the right thing but no server is started and no log information is given.
If I do

WAGsZincAdaptor startOn: 8000

I get a DNU forkAt:named: and after fixing this a unresolved symbol in "Socket newTCP". The last errors indicate there is pharo code where gemstone code should be in place. I loaded zinc and zinc-seaide via

(ConfigurationForHTTPComponents project version: #stable) load: 'Zinc-Seaside'

It tells me it loads version 1.1 which seems quite right. Then I loaded the seaside adaptor manually from gemsource.

Any hints are greatly appreciated,

Norbert

To trouble shoot this I'm going to have to set up a 2.4.4.1 environment.
    I'll let you know when I have some information for you.

Paul



On 12-04-02 07:32 AM, Norbert Hartl wrote:

Thanks in advance Paul,

While looking at the configuration I saw that the adapter is also in the configuration. Trying to load it via the configuration pulled another Zinc package in with a version from you. I really don't know why. It does not change the situation for the workspace but for the console. I can start a zinc server via

WAGsZincAdaptor startGemServerOn: 8001

This gives me a listening socket and I can request the seaside entry page. The server collapses quickly on subsequent requests but it is much more than before :) It would be helpful if you could write down the versions that you are using. So I might find problems myself faster.

thanks again,

Norbert

Am 02.04.2012 um 17:11 schrieb Paul DeBruicker:

On 12-04-02 08:28 AM, Norbert Hartl wrote:
> It would be helpful if you could write down the versions that you are using.

Hi Norbert,

Thats really the problem.  I'm not using any of the versions.  I haven't
looked at it in almost a year.   The FastCGI is faster than Zinc.  Or
was the last time I looked.  Zinc and Swazoo were about the same.  Under
rudimentary apache bench testing anyway.

I would guess that it'll work if you only use versions of Seaside/Zinc
packages available on April 14. 2011 which is the day I published the
working Seaside adapter in the
http://seaside.gemstone.com/ss/ZincHTTPComponents/ repository.  Other
than that I've no idea.

The three moving targets are the Seaside code base, the Gemstone code
base, and the Zinc code base.  I don't know how each has changed in the
past year.

Which versions have you loaded in to your db and from which repo?


FWIW - I think future efforts ought to be put into moving the AJP
adapter up to a more current version. Phillipe was seeing 8k
requests/second on Pharo 1.4. And web adaptor speed/compatability just
isn't a problem I'm having and working on it is definitely a premature
optimization for what I'm working on now.

Good luck

Paul

Am 02.04.2012 um 17:57 schrieb Paul DeBruicker:

> On 12-04-02 08:28 AM, Norbert Hartl wrote:
>> It would be helpful if you could write down the versions that you are using.
>
> Hi Norbert,
>
> Thats really the problem.  I'm not using any of the versions.  I haven't looked at it in almost a year.   The FastCGI is faster than Zinc.  Or was the last time I looked.  Zinc and Swazoo were about the same.  Under rudimentary apache bench testing anyway.
>
Yes, I believe so. But I'm first interested in a reliable setup than in speed. Until today I used fastcgi. I had to look at the code because it didn't work with a new client. It assumes all kind of things like the exact format of headers. Or that a Content-Disposition header is immediately followed by a Content-Type header. So I think it is hard to make anything reliable on top of it other than plain GET or some POST actions. That includes seaside. I'm after http messaging and this is different. I also find fastcgi extremly hard to debug. So to me the best solution is to have a reliable http adaptor and later a fast one (if needed at all). Is there already a AJP connector for gemstone?

> I would guess that it'll work if you only use versions of Seaside/Zinc packages available on April 14. 2011 which is the day I published the working Seaside adapter in the http://seaside.gemstone.com/ss/ZincHTTPComponents/ repository.  Other than that I've no idea.
>
Ok, thanks. I managed to serve some pages and after fixing a bug it is running a little bit more smooth. I got almost frustrated with fastcgi and swazoo (usage and code) and I think I rather invest my time in fixing zinc than the implementation shortcomings of the others.

> The three moving targets are the Seaside code base, the Gemstone code base, and the Zinc code base.  I don't know how each has changed in the past year.
>
> Which versions have you loaded in to your db and from which repo?
>
I'm not sure at the moment :) I think the metacello configuration has everything in it. I'll check again if it works.
>
> FWIW - I think future efforts ought to be put into moving the AJP adapter up to a more current version. Phillipe was seeing 8k requests/second on Pharo 1.4. And web adaptor speed/compatability just isn't a problem I'm having and working on it is definitely a premature optimization for what I'm working on now.
>
The 8k/seqs is just a theoretical maximum value that a certain implementation could serve. As soon as you have more ips involved without keep;alive and doing real stuff it will drop to a number that wouldn't make you so excited.

thanks,

Norbert

Am 2. April 2012 18:21 schrieb Norbert Hartl <[hidden email]>:
No, but if somebody provides me with a Seaside 3.0 GemStone virtual
image I'll port it :-) It has been written in a portable style similar
to Seaside with -Core and -Core-Pharo packages. So one would have to
implement -GemStone-Core. Also it does not use SocketStream :-)

Or actual rendering :-) OTOH as far as I understand the GemStone
session lock a gem will be handling only one request at a time anyway.

Cheers
Philippe

Am 02.04.2012 um 18:37 schrieb Philippe Marschall:

Give me one more day and I might say "deal". I'm running out of options right now. Fastcgi sucks, swazoo does not like to play and zinc does like to play but throws up a lot of errors. And in the processing stage I only have stacktraces in the log file. That are the times I think I would even be better off using java.

Norbert

Y

Norbert,

Presumably the fastCGI issues are fixable ... If there are poor assumptions in the code they can be addressed ... I'm no HTTP expert (which shows), but presumably the issues that you are seeing are not fundamental to FastCGI, but are artifacts of our implementation ...

Because I'm not an expert, I need some specific examples of how the http input that is not handled incorrectly and then I can fix the problem ...

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, April 2, 2012 9:52:01 AM
| Subject: Re: [GS/SS Beta] Instructions to start zinc gs adaptor
|
|
| Am 02.04.2012 um 18:37 schrieb Philippe Marschall:
|
| > Am 2. April 2012 18:21 schrieb Norbert Hartl <[hidden email]>:
| >>
| >> Am 02.04.2012 um 17:57 schrieb Paul DeBruicker:
| >>
| >>> On 12-04-02 08:28 AM, Norbert Hartl wrote:
| >>>> It would be helpful if you could write down the versions that
| >>>> you are using.
| >>>
| >>> Hi Norbert,
| >>>
| >>> Thats really the problem.  I'm not using any of the versions.  I
| >>> haven't looked at it in almost a year.   The FastCGI is faster
| >>> than Zinc.  Or was the last time I looked.  Zinc and Swazoo were
| >>> about the same.  Under rudimentary apache bench testing anyway.
| >>>
| >> Yes, I believe so. But I'm first interested in a reliable setup
| >> than in speed. Until today I used fastcgi. I had to look at the
| >> code because it didn't work with a new client. It assumes all
| >> kind of things like the exact format of headers. Or that a
| >> Content-Disposition header is immediately followed by a
| >> Content-Type header. So I think it is hard to make anything
| >> reliable on top of it other than plain GET or some POST actions.
| >> That includes seaside. I'm after http messaging and this is
| >> different. I also find fastcgi extremly hard to debug. So to me
| >> the best solution is to have a reliable http adaptor and later a
| >> fast one (if needed at all). Is there already a AJP connector for
| >> gemstone?
| >
| > No, but if somebody provides me with a Seaside 3.0 GemStone virtual
| > image I'll port it :-) It has been written in a portable style
| > similar
| > to Seaside with -Core and -Core-Pharo packages. So one would have
| > to
| > implement -GemStone-Core. Also it does not use SocketStream :-)
|
| Give me one more day and I might say "deal". I'm running out of
| options right now. Fastcgi sucks, swazoo does not like to play and
| zinc does like to play but throws up a lot of errors. And in the
| processing stage I only have stacktraces in the log file. That are
| the times I think I would even be better off using java.
|
| Norbert
| >
| >>> I would guess that it'll work if you only use versions of
| >>> Seaside/Zinc packages available on April 14. 2011 which is the
| >>> day I published the working Seaside adapter in the
| >>> http://seaside.gemstone.com/ss/ZincHTTPComponents/ repository.
| >>>  Other than that I've no idea.
| >>>
| >> Ok, thanks. I managed to serve some pages and after fixing a bug
| >> it is running a little bit more smooth. I got almost frustrated
| >> with fastcgi and swazoo (usage and code) and I think I rather
| >> invest my time in fixing zinc than the implementation
| >> shortcomings of the others.
| >>
| >>> The three moving targets are the Seaside code base, the Gemstone
| >>> code base, and the Zinc code base.  I don't know how each has
| >>> changed in the past year.
| >>>
| >>> Which versions have you loaded in to your db and from which repo?
| >>>
| >> I'm not sure at the moment :) I think the metacello configuration
| >> has everything in it. I'll check again if it works.
| >>>
| >>> FWIW - I think future efforts ought to be put into moving the AJP
| >>> adapter up to a more current version. Phillipe was seeing 8k
| >>> requests/second on Pharo 1.4. And web adaptor
| >>> speed/compatability just isn't a problem I'm having and working
| >>> on it is definitely a premature optimization for what I'm
| >>> working on now.
| >>>
| >> The 8k/seqs is just a theoretical maximum value that a certain
| >> implementation could serve. As soon as you have more ips involved
| >> without keep;alive and doing real stuff it will drop to a number
| >> that wouldn't make you so excited.
| >
| > Or actual rendering :-) OTOH as far as I understand the GemStone
| > session lock a gem will be handling only one request at a time
| > anyway.
|
|
| Y
|
|

Am 02.04.2012 um 19:29 schrieb Dale Henrichs:

> Norbert,
>
> Presumably the fastCGI issues are fixable ... If there are poor assumptions in the code they can be addressed ... I'm no HTTP expert (which shows), but presumably the issues that you are seeing are not fundamental to FastCGI, but are artifacts of our implementation ...
>
I know. By saying FastCGI I meant the existing implementation.

> Because I'm not an expert, I need some specific examples of how the http input that is not handled incorrectly and then I can fix the problem ...
>
Take a pharo image and trying sending something like

ZnClient new
        url: 'http://name.of.your.fastcgi.server/';
        addPart: (ZnMimePart
                fieldName: 'akey'
                fileName: 'something'
                entity: (ZnStringEntity text: 'some data text'))

I'm sure you can fix it. But you would fix that single issue and then it breaks elsewhere. I think FastCGI is a good companion if seaside is the goal (or any other GET only API). But looking at the code I have great doubts it can deliver anything more http like. From that point of view you would be better off using Zinc. But that does not seem to be one of your targets. So instead of complaining I could fix it myself but as usual there is no time at the moment. So I could get rid of multipart and hope it works or I could port my code to pharo and use it there. I would like to fix Zinc but that would need some advize from your side how to snap off continuations off early. I tried an hour fixing stuff by only looking at the log files. But that is far too tedious for me at the moment. Maybe you have an easy help with that?

thanks,

Norbert
 

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, April 2, 2012 10:50:51 AM
| Subject: Re: [GS/SS Beta] Instructions to start zinc gs adaptor
|
|
| Am 02.04.2012 um 19:29 schrieb Dale Henrichs:
|
| > Norbert,
| >
| > Presumably the fastCGI issues are fixable ... If there are poor
| > assumptions in the code they can be addressed ... I'm no HTTP
| > expert (which shows), but presumably the issues that you are
| > seeing are not fundamental to FastCGI, but are artifacts of our
| > implementation ...
| >
| I know. By saying FastCGI I meant the existing implementation.
|
| > Because I'm not an expert, I need some specific examples of how the
| > http input that is not handled incorrectly and then I can fix the
| > problem ...
| >
| Take a pharo image and trying sending something like
|
| ZnClient new
| url: 'http://name.of.your.fastcgi.server/';
| addPart: (ZnMimePart
| fieldName: 'akey'
| fileName: 'something'
| entity: (ZnStringEntity text: 'some data text'))
|
| I'm sure you can fix it.

I assume that this is true.

| But you would fix that single issue and then
| it breaks elsewhere.

You mean a different a different http request or are you referring to something else being broken?

| I think FastCGI is a good companion if seaside
| is the goal (or any other GET only API). But looking at the code I
| have great doubts it can deliver anything more http like.

I'm not sure what you are getting at here? If you are referring to the fact that you'd like to do something that did not rely on Seaside, then I agree that I would not want to base a full http server/client framework starting with FastCGI.

If you want a Seaside-less HTTP framework then Zinc is the obvious solution.

| From that
| point of view you would be better off using Zinc. But that does not
| seem to be one of your targets.

It is one of my targets. I have prioritized my efforts on Git/GitHub because I think that trying to collaborate on a project like porting Zinc to GemStone should be done using Git/GitHub rather than trying to use Monticello by itself....

If you are hitting a point where you need Zinc ported now, then I would like to propose that we try to do it with a Git/GitHub project ... I need a couple of days to get things in order for a push on Zinc we can arrange to do that.
 

| So instead of complaining I could
| fix it myself but as usual there is no time at the moment. So I
| could get rid of multipart

If this is your immediate problem, I can try to take a look at your above example and see if I can see a quick fix.

| and hope it works or I could port my code
| to pharo and use it there. I would like to fix Zinc but that would
| need some advize from your side how to snap off continuations off
| early.

If you are talking about snapping off continuations for debugging ... that should be straightforward to do ... if you are talking about integrating continuations into Zinc like Seaside, that will definitely take some effort ...

| I tried an hour fixing stuff by only looking at the log
| files. But that is far too tedious for me at the moment. Maybe you
| have an easy help with that?

I always debug FastCGI/swazoo server issues from GemTools, by launching the server directly in the workspace and using the debugger to address the issues ... It's a bit funky to run the server this way (expecially since swazoo is not well-behaved when terminating processes ... so you occasionally need to browse the processes and kill off all of the server threads) ... but much easier to do than using the log file ...

You should also be able to dump continuations to the object log ... I suppose it never occurred to me to put the object log hooks there, but they certainly can be added. DebuggerLogEntry class>>createContinuationLabeled: basically does all of the work of stashing a continuation in the object log and letting you bring up a debugger on it. Try:

  DebuggerLogEntry createContinuationLabeled: 'testing'

Then go to the Debug menu and bring up the contuation...The trick is that you need to arrange for a commit to occur to save the continuation in the object log and have it accessible to another gem ... I didn't think that it was a good idea to do this in general, but under development conditions it makes perfect sense ...This call can be added into the FastCGI error handling logicwith a flag for enabling continuations ... I can look into that today ...

Dale
|
| thanks,
|
| Norbert
|  

Dale,

Am 02.04.2012 um 20:46 schrieb Dale Henrichs:

No, it is two-fold. If I encounter problems in the beginning of some processing I expect more to come later on. I have my use case in mind. FastCGI gains performance by directly operating on the stream. This way information is sucked up just as needed but the information isn't that structured as you might need it afterwards. I saw this problem with Kom first and FastCGI is next. It is just closely tight to its need without much potential to improve. But that is fine for the purpose it fulfills right now.
>
> | I think FastCGI is a good companion if seaside
> | is the goal (or any other GET only API). But looking at the code I
> | have great doubts it can deliver anything more http like.
>
> I'm not sure what you are getting at here? If you are referring to the fact that you'd like to do something that did not rely on Seaside, then I agree that I would not want to base a full http server/client framework starting with FastCGI.
>
That's what I meant. I use a great deal of post sends containing either urlencoded or multipart types. At the moment I could live without multipart but I just would postpone the problem.

> If you want a Seaside-less HTTP framework then Zinc is the obvious solution.
>
Yes, I wasn't clear on that. In the end I need both, doing pure http web api and serving seaside. That means I need all of the header fiddeling, body entities mangeling and all of the http verbs to operate.

> | From that
> | point of view you would be better off using Zinc. But that does not
> | seem to be one of your targets.
>
> It is one of my targets. I have prioritized my efforts on Git/GitHub because I think that trying to collaborate on a project like porting Zinc to GemStone should be done using Git/GitHub rather than trying to use Monticello by itself....
>
> If you are hitting a point where you need Zinc ported now, then I would like to propose that we try to do it with a Git/GitHub project ... I need a couple of days to get things in order for a push on Zinc we can arrange to do that.
>
Ok, sounds like a plan. I have immediate needs so I need a workaround for the time being.
>
> | So instead of complaining I could
> | fix it myself but as usual there is no time at the moment. So I
> | could get rid of multipart
>
> If this is your immediate problem, I can try to take a look at your above example and see if I can see a quick fix.

That would be nice. The problems are: parsing of the Content-Dispositon header. It expects exactly one space after a semicolon for keys name, filename and so on. Zinc sends them without space and boom. The next thing is the expectation that Content-Disposition is followed by Content-Type. There is no defined ordering of http headers. In my case it was a Content-Length header between Content-Disposition and Content-Type and this is absolutely feasible. The strange thing is that I discovered that today because the api is online since one year :) But ios clients seems to resemble the FastCGI behaviour .
>
> | and hope it works or I could port my code
> | to pharo and use it there. I would like to fix Zinc but that would
> | need some advize from your side how to snap off continuations off
> | early.
>
> If you are talking about snapping off continuations for debugging ... that should be straightforward to do ... if you are talking about integrating continuations into Zinc like Seaside, that will definitely take some effort ...

Yes, debugging.
>
> | I tried an hour fixing stuff by only looking at the log
> | files. But that is far too tedious for me at the moment. Maybe you
> | have an easy help with that?
>
> I always debug FastCGI/swazoo server issues from GemTools, by launching the server directly in the workspace and using the debugger to address the issues ... It's a bit funky to run the server this way (expecially since swazoo is not well-behaved when terminating processes ... so you occasionally need to browse the processes and kill off all of the server threads) ... but much easier to do than using the log file ...
>
I used this but stopped. Often the gemtools session got killed by an error and I had to logout and back in without a resulting debugger.

> You should also be able to dump continuations to the object log ... I suppose it never occurred to me to put the object log hooks there, but they certainly can be added. DebuggerLogEntry class>>createContinuationLabeled: basically does all of the work of stashing a continuation in the object log and letting you bring up a debugger on it. Try:
>
>  DebuggerLogEntry createContinuationLabeled: 'testing'
>
Ah, I wasn't remembering this one. So I take the fastcgi script and start my adapter and add an exception handler that snaps off a continuation for the object log and commits. It exits after anyway :)

> Then go to the Debug menu and bring up the contuation...The trick is that you need to arrange for a commit to occur to save the continuation in the object log and have it accessible to another gem ... I didn't think that it was a good idea to do this in general, but under development conditions it makes perfect sense ...This call can be added into the FastCGI error handling logicwith a flag for enabling continuations ... I can look into that today ...
>
Ok, Dale, I think it would be good for FastCGI to fix those problems. I don't know if it needs to be done now. I will try to solve my issue another (quicker) way. This way I can keep going in my project and spare some cycles to help with the zinc port.

thanks,

Norbert

Understood ... the time when you need the fix you don't have time to do it and when you don't need it there are more important things:)

I've submitted a couple of bugs on FastCGI and as soon as the git stuff is ready we can start addressing the port of Zinc to GemStone...

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, April 2, 2012 12:09:01 PM
| Subject: Re: [GS/SS Beta] Instructions to start zinc gs adaptor
|
| Dale,
|
| Am 02.04.2012 um 20:46 schrieb Dale Henrichs:
|
| >
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Monday, April 2, 2012 10:50:51 AM
| > | Subject: Re: [GS/SS Beta] Instructions to start zinc gs adaptor
| > |
| > |
| > | Am 02.04.2012 um 19:29 schrieb Dale Henrichs:
| > |
| > | > Norbert,
| > | >
| > | > Presumably the fastCGI issues are fixable ... If there are poor
| > | > assumptions in the code they can be addressed ... I'm no HTTP
| > | > expert (which shows), but presumably the issues that you are
| > | > seeing are not fundamental to FastCGI, but are artifacts of our
| > | > implementation ...
| > | >
| > | I know. By saying FastCGI I meant the existing implementation.
| > |
| > | > Because I'm not an expert, I need some specific examples of how
| > | > the
| > | > http input that is not handled incorrectly and then I can fix
| > | > the
| > | > problem ...
| > | >
| > | Take a pharo image and trying sending something like
| > |
| > | ZnClient new
| > | url: 'http://name.of.your.fastcgi.server/';
| > | addPart: (ZnMimePart
| > | fieldName: 'akey'
| > | fileName: 'something'
| > | entity: (ZnStringEntity text: 'some data text'))
| > |
| > | I'm sure you can fix it.
| >
| > I assume that this is true.
| >
| > | But you would fix that single issue and then
| > | it breaks elsewhere.
| >
| > You mean a different a different http request or are you referring
| > to something else being broken?
|
| No, it is two-fold. If I encounter problems in the beginning of some
| processing I expect more to come later on. I have my use case in
| mind. FastCGI gains performance by directly operating on the stream.
| This way information is sucked up just as needed but the information
| isn't that structured as you might need it afterwards. I saw this
| problem with Kom first and FastCGI is next. It is just closely tight
| to its need without much potential to improve. But that is fine for
| the purpose it fulfills right now.
| >
| > | I think FastCGI is a good companion if seaside
| > | is the goal (or any other GET only API). But looking at the code
| > | I
| > | have great doubts it can deliver anything more http like.
| >
| > I'm not sure what you are getting at here? If you are referring to
| > the fact that you'd like to do something that did not rely on
| > Seaside, then I agree that I would not want to base a full http
| > server/client framework starting with FastCGI.
| >
| That's what I meant. I use a great deal of post sends containing
| either urlencoded or multipart types. At the moment I could live
| without multipart but I just would postpone the problem.
|
| > If you want a Seaside-less HTTP framework then Zinc is the obvious
| > solution.
| >
| Yes, I wasn't clear on that. In the end I need both, doing pure http
| web api and serving seaside. That means I need all of the header
| fiddeling, body entities mangeling and all of the http verbs to
| operate.
|
| > | From that
| > | point of view you would be better off using Zinc. But that does
| > | not
| > | seem to be one of your targets.
| >
| > It is one of my targets. I have prioritized my efforts on
| > Git/GitHub because I think that trying to collaborate on a project
| > like porting Zinc to GemStone should be done using Git/GitHub
| > rather than trying to use Monticello by itself....
| >
| > If you are hitting a point where you need Zinc ported now, then I
| > would like to propose that we try to do it with a Git/GitHub
| > project ... I need a couple of days to get things in order for a
| > push on Zinc we can arrange to do that.
| >
| Ok, sounds like a plan. I have immediate needs so I need a workaround
| for the time being.
| >
| > | So instead of complaining I could
| > | fix it myself but as usual there is no time at the moment. So I
| > | could get rid of multipart
| >
| > If this is your immediate problem, I can try to take a look at your
| > above example and see if I can see a quick fix.
|
| That would be nice. The problems are: parsing of the
| Content-Dispositon header. It expects exactly one space after a
| semicolon for keys name, filename and so on. Zinc sends them without
| space and boom. The next thing is the expectation that
| Content-Disposition is followed by Content-Type. There is no defined
| ordering of http headers. In my case it was a Content-Length header
| between Content-Disposition and Content-Type and this is absolutely
| feasible. The strange thing is that I discovered that today because
| the api is online since one year :) But ios clients seems to
| resemble the FastCGI behaviour .
| >
| > | and hope it works or I could port my code
| > | to pharo and use it there. I would like to fix Zinc but that
| > | would
| > | need some advize from your side how to snap off continuations off
| > | early.
| >
| > If you are talking about snapping off continuations for debugging
| > ... that should be straightforward to do ... if you are talking
| > about integrating continuations into Zinc like Seaside, that will
| > definitely take some effort ...
|
| Yes, debugging.
| >
| > | I tried an hour fixing stuff by only looking at the log
| > | files. But that is far too tedious for me at the moment. Maybe
| > | you
| > | have an easy help with that?
| >
| > I always debug FastCGI/swazoo server issues from GemTools, by
| > launching the server directly in the workspace and using the
| > debugger to address the issues ... It's a bit funky to run the
| > server this way (expecially since swazoo is not well-behaved when
| > terminating processes ... so you occasionally need to browse the
| > processes and kill off all of the server threads) ... but much
| > easier to do than using the log file ...
| >
| I used this but stopped. Often the gemtools session got killed by an
| error and I had to logout and back in without a resulting debugger.
|
| > You should also be able to dump continuations to the object log ...
| > I suppose it never occurred to me to put the object log hooks
| > there, but they certainly can be added. DebuggerLogEntry
| > class>>createContinuationLabeled: basically does all of the work
| > of stashing a continuation in the object log and letting you bring
| > up a debugger on it. Try:
| >
| >  DebuggerLogEntry createContinuationLabeled: 'testing'
| >
| Ah, I wasn't remembering this one. So I take the fastcgi script and
| start my adapter and add an exception handler that snaps off a
| continuation for the object log and commits. It exits after anyway
| :)
|
| > Then go to the Debug menu and bring up the contuation...The trick
| > is that you need to arrange for a commit to occur to save the
| > continuation in the object log and have it accessible to another
| > gem ... I didn't think that it was a good idea to do this in
| > general, but under development conditions it makes perfect sense
| > ...This call can be added into the FastCGI error handling
| > logicwith a flag for enabling continuations ... I can look into
| > that today ...
| >
| Ok, Dale, I think it would be good for FastCGI to fix those problems.
| I don't know if it needs to be done now. I will try to solve my
| issue another (quicker) way. This way I can keep going in my project
| and spare some cycles to help with the zinc port.
|
| thanks,
|
| Norbert
|
|

On 12-04-02 09:37 AM, Philippe Marschall wrote:
> No, but if somebody provides me with a Seaside 3.0 GemStone virtual
> image I'll port it:-)  It has been written in a portable style similar
> to Seaside with -Core and -Core-Pharo packages. So one would have to
> implement -GemStone-Core. Also it does not use SocketStream:-)


What OS would you like it on?  VirtualBox or VMWare?

Am 4. April 2012 04:38 schrieb Paul DeBruicker <[hidden email]>:
Linux preferably. The important thing is that it has an Apache 2.2+
with mod_proxy_ajp [1]. This should ship with Apache 2.2 and if it
doesn't it's usually very easy to install an additional module on
Linux.

> VirtualBox or VMWare?

Don't care.

 [1] http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html

Cheers
Philippe

On 12-04-03 11:25 PM, Philippe Marschall wrote:

OK.  I've got a debian 6 virtualbox vm with:

Pharo 1.3 + Seaside 3.0.7
GLASS 1.0b7.1 + Seaside 3.0.7
GemTools 1.0-b6 set up to connect to the GLASS install on localhost.

Apache 2.2 + mod_proxy_ajp

username: gemstone
password: glass

username: root
password: glass


Its 3.1GB.  Where should I put it?