[Glass] Free Gems
Locked
 
|
Ciao,
i have my Seaside application ported to GLASS 3.1.0.4 which manage some TCP/IP tickets printers devices. Now when one session send data to one specific printer device, for don't lose data i need to insert: ( Delay forMilliseconds: 6000) wait.] every ten tickets. In this mode the printer device maintain the buffer ready to receive new data. Now if i have three printer device which printing many tickets at the same time, my three Gems is occupied to manage it. In this situation any other web request is not management, and the system is seeming blocked, until the printer end the printing. It's my considerations right !? I can add more gems to my GLASS environment ( i use WAFastCGIAdaptor gem )? What, add gems to the system, implies ? Thanks for any considerations, Dario _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
On Thu, Jun 5, 2014 at 8:52 AM, Dario Trussardi <[hidden email]> wrote: Ciao, Yes you can. In 3.1.0.4 there is NO limit in the number of gems regarding the license. Note that this has changed in 3.2 (you have up to 20 free). What, add gems to the system, implies ? In a general point of view, I see it like simply having more Smalltalk VMs processing the bytecodes of my app :) Now...if you app happens to be a web app, those "bytecode processing" may be "listening and processing requests". So more gems, more Smalltalk VMs being able to listen and process requests. So yes, I think it will help you your case, even if I could be a workaround.
Best, Thanks for any considerations, Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Mariano is correct; the rule of thumb is that you should have enough Seaside gems running to cover the number of concurrent requests. so if you can have 10 concurrent requests (on a regular basis), then you need 10 gems to avoid having requests get stuck waiting in line ... Soo, for your printer case, one solution is to add more Seaside gems or you can offload your printer jobs to one or more service vms[1]. Using a service vm, means that your Seaside vm will offload long running tasks (like printer jobs or processing paypal transacations) into a separate vm, you can arrange to have the browser poll for a task completion.
The service vm, is designed to allow multiple threads running concurrently with the expectation that most of the threads are busy waiting on external resources ... a transaction mutex is used to keep threads in the service vm from stepping on each other ...
As I look at the Service vm example[1], it occurs to me that the REST code might not load anymore, because a package that I depended upon kept getting deleted from the repository. The REST code was only needed for the example to run. the service vm work was done as an extension of the maintenance vm ...
If you give me several days, I will make a pass through the example code and make sure that it is loadable ... I will also move it to github and update the documentation a bit ...
While I'm fiddling with the code, it is worth reading through the discussion that Nick Ager and I had where this scheme was cooked up[2]. There's quite a bit of detail there about the things to consider ... Also Nick talks about his work on futures using the service vm ... and I'll want to update that code as well (I don't think it was ever added to the configuration) ... I'm also trying to get tODE ready ... Hmmm, the first order of business is to make sure that the service vm support code is working correctly in GemStone3.x ... I'll do that first and outline some workspace-based code that will provide example code for initiating work in the service vm from the client ... the examples and updated documentation can wait a bit:)
Dale On Thu, Jun 5, 2014 at 5:18 AM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by Mariano Martinez Peck
We have now successful used Gemstone in our first event - and it was
very successful. This was a purely REST-based system with Sencha-UI and some C# (Mono) clients using the same REST-API. Some ideas from that event: -> one C# client (can) create more load than tens of users. -> long term REST-API calls must result in background jobs in Gemstone I've written some of these background jobs in an external C# client because then ALL clients (browser and fat clients) use the same API - that's much smarter while developing and it works extremely well. I'm now working on 0MQ-library for Gemstone - to make ipc communication between Gemstone and external clients much better - resulting in an active Gemstone system. And external C# clients consume less CPU power from that 2-CPU license restriction of Gemstone. And writing C# clients is a very well indication (for other developers, bosses, etc...), that the solution is NOT a Smalltalk-centric-only application (remvoing the fear for the future without Smalltalk). Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Marten, That sounds like a reasonable approach ... the service vm is useful if you must access shared gemstone data, but an external process is a good option. Do you happen to have any classes that you can share for managing and initiating these external processes? It helps to have a little bit of code to start with if one wants to go this route.
Dale On Thu, Jun 5, 2014 at 7:51 AM, [hidden email] <[hidden email]> wrote: We have now successful used Gemstone in our first event - and it was _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by Dale Henrichs-3
With one thing and another I was able to find enough time in the last week or so to write up a fresh take on the service vm[1]. The writeup has a little bit of everything ... new shell scripts to install in $GEMSTONE/seaside/bin (and a script to do the install). documentation, code, and tools support (tODE scripts) all in one place ... Besides describing the operation of the ServiceVM, you should be able to get a flavor for the things that tODE will be bringing to the table as there's a section on using tODE to install and control the service vms using tODE[2]. The service vm example itself has been updated to work with Seaside3.1 and has been tested with GemStone3.1 and GemStone3.2. There is more work to do in this area, but I'm sure that the new writeup is a step up from the old page[3] (yes I will put a link from the old page to the new docs ... )
The default web server is Zinc for the example, so yes I am close to being able to publish the formula for using Zinc and Seaside3.1 with GemStone 3.x ... Let me know if you have any questions or comments. Pull requests with fixes or new material/examples are welcome ... this is your resource!
Dale
On Thu, Jun 5, 2014 at 7:00 AM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ 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 |