Hi All!
I finally started to port one of my prototypes to Gemstone/Web. My Pharo portotype uses Seaside and Seaside-REST and Amber as a frontend. I used the most current 3.1.0.4 version of Gemstone and I was wondering if somebody can give me some tips on how to startup Zinc. I do not really need Seaside and I would prefer to use Zinc-Rest for my kind of application.... I know that there are test failing currently but I'm not too sure if my loaded code base is the right one anyways. Is there somebody how has at least managed to start a Zinc Server on 3.1.0.X and if so,... what did you load and how do you start it ;-) Thanks for you help! Sebastian _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Sebastian,
We're using Zinc on 3.1.0.1 (hopefully upgrading to 3.1.0.4 this week). I don't remember everything I had to do to get it working, but I know it involved at least: * Using a 3.1.0.X port of Zinc. Feel free to use my hacked versions here: * Configuring WAGemStoneRunSeasideGems to use Zinc adaptors. Something like: WAGemStoneRunSeasideGems default name: 'Zinc'; adaptorClass: WAGsZincAdaptor; ports: #(9001 9002 9003). Hope that helps, -- Ken Treis Miriam Technologies, Inc. (866) 652-2040 x221 On Jul 1, 2013, at 2:01 PM, Sebastian Heidbrink wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Ken,
thank you for the feedback! So, you are using the SeasideAdaptors,.... do you also have experience using Zinc without any Seaside parts at all? I have trouble firing a ZnServer up. I'll have a look at your surces and analize that script. Maybe I can go one from there now! Thanks a lot again! Sebastian Am 02.07.2013 07:35, schrieb Ken Treis: Hi Sebastian, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
I've never used Zinc in GemStone without the Seaside adaptors, but it shouldn't be too difficult to get Zinc running. To see the basic pattern, look at the startSeaside30_Adaptor script (in $GEMSTONE/seaside/bin), WAGemStoneRunSeasideGems class>>startGemServerOn:, and the Zinc adaptor class.
You'll be launching a topaz process for every Zinc backend that you want to run, and within topaz you'll instantiate your Zinc server and start it. While it runs (in its own thread), you'll keep the main thread busy with an infinite loop. You'll also need to manage transactions yourself, which can be a little tricky. The Seaside code uses a big lock to make sure that only one thread can be in a transaction at a time, since GemStone's transactions are per-session and not per-thread. This alone might argue for using Seaside-REST over Zinc-REST, but you know your project and your needs better than I do. :) -- Ken Treis Miriam Technologies, Inc. (866) 652-2040 x221 On Jul 2, 2013, at 7:44 AM, Sebastian Heidbrink wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Ken Treis
Ken, Does your hacked version match the version that is up on github[1]? I just took a quick look at the Zinc test failures for 3.1 and they are the familiar fork:at: issue, so I was planning on merging the changes that you'd made on github, but if there are additional hacks not on github, I probably should include them as well ... Sebastian, the 3.1 test failures in the current glassdb version are pretty fundamental so I'd recommend going with Ken's port until I can get his edits integrated... Dale [1] https://github.com/ktreis/zinc From: "Ken Treis" <[hidden email]> _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Looks like you've got later packages in your repository[1] than github, so I'll use them to do the merge... Dale [1] http://mc.miriamtech.com/zinc/ From: "Dale K. Henrichs" <[hidden email]> _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Dale Henrichs-3
<base href="x-msg://1096/">Hi Dale,
I haven't played with the git stuff for a while. I need to get back into that. I think the main changes that I haven't pushed to Github are: 1. Adding SpSocketError to the pile of exceptions handled by the read/writeRequestSafely: methods 2. Increasing the maximumNumberOfDictionaryEntries. You wouldn't have to merge #2. Our app needed it because we have some big forms, but unfortunately there was no clean way to override the default (say in ZnConstants) without changing the code. Other than that, there are some streaming packages. We're using these, together with another hacked backport of WAComboRequest, to send results to the browser in chunks. There's no clean way to handle transaction failure when you're doing that, so we only use it in combination with an unlock and abort. Again, no need to merge those. I also started to shuffle some code around to better match what Sven has done upstream, but I didn't get very far on that project either. Pesky deadlines... -- Ken Treis Miriam Technologies, Inc. (866) 652-2040 x221 On Jul 2, 2013, at 9:25 AM, Dale K. Henrichs wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Ken Treis
Hi Sebastian,
I can't offer too many details on the project itself, but it's built in Seaside and uses Seaside-REST in addition to regular Seaside components. We're migrating from Seaside 2.8 on VisualWorks to Seaside 3 on GLASS, but we're doing it incrementally. Right now, we're using a custom RESTful synchronization protocol that we use to move data between VW and GemStone. That same protocol is used to sync with about 50 desktop clients. To keep GemStone responsive when you get a big request, you should consider running multiple Zinc backends. We currently proxy to 4 backends using Apache with mod_proxy_balancer and lbmethod=bybusyness. This routes incoming HTTP requests to the least-busy backend. -- Ken Treis Miriam Technologies, Inc. (866) 652-2040 x221 On Jul 2, 2013, at 10:20 AM, Sebastian Heidbrink wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Sebastian, I second what Ken is recommending ... the rule of thumb for GemStone web clients is that you should spin up enough gems to cover the "max" number of concurrent HTTP ... A single gem can handle only one concurrent (write) request at a time .... In theory a single gem could handle multiple read only requests, but you'd have to be able to sort that out at the Apache/lighttd/nginx level ... The Seaside-REST implementation for GemStone does avoid creating session state when handling a REST request, but if you want to handle multiple concurrent read requests, you still have to manage your aborts ... you cannot afford to have each request abort, because you'd end up with aborts occuring mid-request ... so under the right circumstances it can be done... Dale From: "Ken Treis" <[hidden email]> _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Ken Treis
From: "Ken Treis" <[hidden email]>The theory with GitHub is that we would issue pull requests against Sven's implementation with improvements like this ... then it would be up to Sven to accept the request, ask for changes, or decide not to include it ... Without critical mass, there isn't much incentive to move to github (despite the benefits) ... I'm hoping to move closer to critical mass by moving the GLASS environment to github:) Okay, I'll be picky about what I merge into the Zinc gemstone3.1 branch and invite you to submit pull requests in the future when you find things that you think are worth sharing ... Hmm, I think I will create a Ken branch to track all of your public changes and then cherry-pick the commits that make sense to the gemstone3.1 branch (Yes I will do a git commit per package version ... there aren't that many chagnes to deal with:).... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Ken Treis
Ken, I took a look at the differences between the packages in your repository and the packages that have been updated to Zinc 2.3.2 and there are quite a few changes (the set of changes that Johan waded through when he did the port...), soooo it won't be easy for me to extract anything else from your repo. We've got the 2.3.2 release tagged for Gemstone 2.4 and 3.1, so the next step for me is to sync up with the current Zinc release and start work on getting the new release ported (at a leisurely pace) ... the master branch in the Zinc repo is supposed to pretty much match Svens repo, so I'll offer Sven a pull request once I've got things up there (I might even add travis tests for Pharo as a bonus) to entice him to continue to keep the github repo up-to-date:) When we've got the core of Sven's latest ported the plan would be to expand out into the other packages followed by a Zodiac port to 3.1...eventually. Dale From: "Ken Treis" <[hidden email]> _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
<base href="x-msg://1168/">No problem, Dale. All the more reason for me to get back into gitacello.
I'm glad to hear that the Zinc port is more up to date than when I started hacking. -- Ken Treis Miriam Technologies, Inc. (866) 652-2040 x221 On Jul 2, 2013, at 4:36 PM, Dale K. Henrichs wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |