[Glass] Free Gems

[Dale Henrichs]

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

[1] https://code.google.com/p/glassdb/wiki/ServiceVMExample
[2] http://forum.world.st/threads-within-a-request-td2335295.html#a2335295


On Thu, Jun 5, 2014 at 5:18 AM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

>
>
>
> On Thu, Jun 5, 2014 at 8:52 AM, Dario Trussardi <
> dario.trussardi at tiscali.it> wrote:
>
>> 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 )?
>>
>>
> 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,
>>
>>                 Dario
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140605/c5e919a3/attachment.html>