<html><head> </head>Hi Sebastian, the current version of the clara defines a service such that it has only one execute service method, i.e. single algorithm. You are right if we configure algorithm we fix the service functionality. The suggestion of 2.3.1 is to clone or run multiple services in a container. The new version, that I am planning to release before Christmas will allow named inputs and outputs, meaning that services will have different algorithms (execute-methods) for different named inputs. -vardan <p>Sent on the Sprint® Now Network from my BlackBerry®</p><hr><div><b>From: </b> Sebastián Mancilla <smancill@jlab.org>
</div><div><b>Date: </b>Fri, 4 Nov 2011 16:42:08 -0300</div><div><b>To: </b>Vardan Gyurjyan<gurjyan@jlab.org></div><div><b>Cc: </b>Johann Goetz<jgoetz@ucla.edu>; Gagik Gavalian<gavalian@jlab.org>; Dennis Weygand<weygand@jlab.org>; <clas12_software@jlab.org>; BMK Nefkens<bmknefkens@gmail.com></div><div><b>Subject: </b>Re: bos2evio as a clara service.</div><div><br></div>Hi<div><br></div><div>I have a design question about these kind of "feeder" services that read files and return events.</div><div><br></div><div>I understand that the idea of CLARA is to deploy the services in containers (in a node), and everyone can request the service, in any time, i.e, the service can be requested by multiple users in parallel, and those executions do not interfere with each other.</div>
<div><br></div><div>But when a service is configured to read an specific input file (like this one or the EventService.java), the capacity to support multiple users in parallel is lost, because the service is locked to read a certain file, and other users who want to read different files cannot do it without reconfiguring the service (and interfering with the current user).</div>
<div><br></div><div>How should this situations be handled? If another user needs to use the service to get the events that he wants, he has to deploy it in a different container? Or the CLARA CService interface will be updated to know the ID of the user requesting a service (and therefore a service will be able to handle parallel configurations for several users)?</div>
<div><br></div><div><br></div><div>Best regards</div><div><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 2:17 PM, Vardan Gyurjyan <<a href="mailto:gurjyan@jlab.org">gurjyan@jlab.org</a>> wrote:<br>
<blockquote class="gmail_quote">Hi Johann,<br>
How you envision implementing 1-a and 2-a functionalities?<br>
My suggestion would be using service-configure mechanism of the framework.<br>
What you think?<br>
-vardan<br>
<br>
Johann Goetz wrote:<br>
<blockquote class="gmail_quote"><div><div class="h5">
Hi guys,<br>
I have converted the bos2evio program to a CLARA service. It currently uses a mixture of the old and new CLARA libraries. I tagged it as version 1.1 of the bos2evio project on the repository. It ships with all dependencies except SCons and gcc. It compiles fine but may not work too well (read: proven correct, but untested).<br>
<br>
After some discussion with myself, Gagik and Vardan, the future plans for this program/service are:<br>
1) ship bank definitions in XML with EVIO buffer<br>
a) requester can ask not to receive bank definitions<br>
b) requester should be able to compare bank definitions XML string with md5sum or similar to see if he needs to re-parse the XML<br>
2) ship more than one event<br>
a) requester should be able to specify number of events or maximum size for buffer<br>
3) configuration to tell it which bos files to read<br>
<br>
This program is very much NOT thread-safe because of the bosio library underneath. I am not sure what to do about that.<br>
<br>
checkout and compiling should be straightforward. The last command uses the newer SCons in the CUE in /apps and "-j16" tells scons to parallelize the build to 16 threads:<br>
<br>
svn co <a href="https://clas12svn.jlab.org/repos/clas12/bos2evio/tags/bos2evio_1.1">https://clas12svn.jlab.org/<u></u>repos/clas12/bos2evio/tags/<u></u>bos2evio_1.1</a> bos2evio<br>
cd bos2evio<br>
/apps/scons/bin/scons -j16<br>
build/bin/bos2evio-service -h<br>
<br>
Generic options:<br>
-h [ --help ] produce help message.<br>
-q [ --quiet ] quiet mode.<br>
-v [ --verbose ] verbose mode.<br>
-b [ --bankdefs ] arg (=/u/home/clasg12/test/<u></u>bos2evio/external/bankdefs)<br>
directory containing bank definition<br>
XML files.<br>
<br>
CLARA Options:<br>
--clara-host arg (=localhost) The name of the CLARA host.<br>
--clara-name arg (=ClaraPlatform) The name of the CLARA platform.<br>
<br>
CLARA service name: BOS to EVIO Service<br>
author: Johann Goetz<br>
version: 0.1<br>
<br>
This service reads in BOS files and waits for input of type<br>
string with value of "next" and returns a single event<br>
converted into the EVIO format. The EVIO buffer is prepended<br>
with a 32bit unsigned int of value 0x12345678 which can be<br>
used to determine if swapping is neccessary.<br>
<br>
-- <br></div></div>
Johann T. Goetz, PhD. <<a href="http://sites.google.com/site/theodoregoetz/">http://sites.google.com/site/<u></u>theodoregoetz/</a>><br>
<a href="mailto:jgoetz@ucla.edu">jgoetz@ucla.edu</a> <mailto:<a href="mailto:jgoetz@ucla.edu">jgoetz@ucla.edu</a>><div class="im"><br>
Nefkens Group, UCLA Dept. of Physics & Astronomy<br>
Hall-B, Jefferson Lab, Newport News, VA<br></div>
Office: 757-269-5465 <tel:757-269-5465> (CEBAF Center F-335)<br>
Mobile: 757-768-9999 <tel:757-768-9999><br>
<br>
</blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Sebastian Mancilla Matta<br>Est. Ingenieria Civil Informatica UTFSM<br>Valparaiso - Chile<br>
</div>
</html>