Seaside object log
Locked
 
Administrator
|
A customer is considering moving their application to GemStone-based Seaside. They have a feature in their application that they would like to preserve, at least in spirit. Can anyone advise me on whether it's possible and practical, and if so what the approach would entail?
Because their system is a "REST-like" two-tier application, they can record the request and response strings they use to exchange data between the client Seaside machine and the GemStone server. The strings are Smalltalk expressions, so they can be debugged interactively when there are problems or even to recreate specific successful scenarios. They have expressed no prior constraints on how it should be done, but they want the comparable ability to capture requests and responses, both successes and failures, and be able to rerun them and debug them. Thanks everyone! |
|
Within gemstone you can obviously collect the incoming data, outgoing response and log that to a file. Beware of sync etc to ensure the file is current upon a crash. Another thought is generally I setup a nginx server to support the https:// SSL and then do a fastcgi_pass seaside;to the gemstone database. You'd need to talk to a nginx expert or apache guy to determine if you can log the input/output stream given to the fast CGI interface so that you avoid having to bother with code changes in the gemstone/smalltalk side. Might have to write a custom module. In all this I do wonder about concurrency... But maybe sending to syslog will work all that out for you. On Tue, Jun 28, 2016 at 4:34 PM, Richard Sargent via Glass <[hidden email]> wrote: A customer is considering moving their application to GemStone-based Seaside. =========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by Richard Sargent
Taking inspiration from http://mutabit.com/offray/blog/es/entry/ds-twitter-mockup, how about using Fuel serialization/deserialization to a SQL database blob. So the trimmed object-graph, from which the request/response strings are generated, would be serialized to a SQL database. For replay, you could deserialize the blobs from the database. The SQL database would not burden GemStone with debug log information, and would avoid the mess of log files. It would introduce another point of failure though - but maybe not, if you consider that the filesystem can always fill up.
On Tue, Jun 28, 2016 at 7:34 PM, Richard Sargent via Glass <[hidden email]> wrote: A customer is considering moving their application to GemStone-based Seaside. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |