Re: Integrating Calabash in a Web application

Hi Florent!

I did see the sample code there which is actually loading xpipeline with 
runtime.load() all the time.
In my scenario, I'd like to cache such pipelines as I see just creating 
them again and again would take double the time that actually whole 
pipeline takes to execute if cached. TPS is of utmost important for me.

Okay, now lets talk about caching pipelines.

Is this is a viable solution?

I create 10 runtime with say a set of 20  different loaded pipelines each.

I'll have a pool of 200 (10 instances of an identical pipeline each) 
pipelines this way.

I'll make sure a single type of pipeline per runtime is accessed only by 
one thread at a time. In pressure times, if all 10 (similar) pipeline 
instances are being executed I'll just queue the remaining request.

Is this what caching of xpipeline is all about? Do I really need 10 
runtimes to cache 10 instances of a pipeline?


Thanks a million,
Alam Sher


On 2/9/2011 4:30 AM, Florent Georges wrote:
> On 9 February 2011 00:06, Alam Sher wrote:
>
>    Hi,
>
>> Also I would like to cache each pipeline in a way that I don't
>> have to initiate it again and again and just execute it with the input
>> document in source port.
>    Of course, Norm will give you more accurate answers, but from
> my own experience, the short answer is no.  This is because
> XPipeline is both the compiled form and the runtime object.  So
> theoretically, you can reset the object and reuse it, but within
> a multithreaded environment, you will have to create a pool of
> pipelines and be sure threads wait for an available pipeline as
> well as enforcing reseting the pipeline after use.
>
>    In Servlex<http://code.google.com/p/servlex/>, I then chose
> not to cache pipelines (though I properly cache stylesheets and
> queries).  You can have a look at the class XProcPipeline[1] in
> Servlex's trunk if you want to see a real example.
>
>    Regards,
>


-- 
*Alam Sher Khan*
Lead Engineer, Billing & Integration
http://www.AdvOSS.com
+92 321 512 6543

Received on Wednesday, 9 February 2011 00:37:24 UTC