<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi,</div><div>The FT services use the ConstantManager, similarly to the ec, except for accessing the geometry table because that was created long ago and doesn’t have the sector, layer, component indexes. The errors Vardan reported seems to be related to ccdb acceded via the ConstantsManager since that retrieves IndexedTables but the fact that those happen only on the online machine is very puzzling. </div><div>Vardan, can you send the log with the errors you get? Also, can I try myself on clonfarm0 to see what happens?</div><div>Thanks,</div><div>Raffaella </div><div><br>Il giorno 03 mar 2018, alle ore 03:38, Francois-Xavier Girod <<a href="mailto:fxgirod@jlab.org">fxgirod@jlab.org</a>> ha scritto:<br><br></div><blockquote type="cite"><div><div dir="ltr">I just installed the version 5a.1.1 and tested it on clara1602 with <div><br></div>/u/scratch/fxgirod/test/clas_003512.evio.1400.hipo<div><br><div>The log is attached</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 2, 2018 at 8:51 PM, Nathan Baltzell <span dir="ltr"><<a href="mailto:baltzell@jlab.org" target="_blank">baltzell@jlab.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Will be good to give people a reference model. I based EB’s CCDB access on ECAL's.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Nathan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Mar 2, 2018, at 8:40 PM, Gagik Gavalian <<a href="mailto:gavalian@jlab.org">gavalian@jlab.org</a>> wrote:<br>
><br>
> We have tools for accessing the database, which are safe. It is adviced that people use those to avoid problem, but it’s not enforced.<br>
><br>
> Gagik<br>
><br>
> Sent from my iPhone<br>
><br>
> On Mar 2, 2018, at 8:31 PM, Francois-Xavier Girod <<a href="mailto:fxgirod@jlab.org">fxgirod@jlab.org</a>> wrote:<br>
><br>
>> Dear Vardan<br>
>><br>
>> Can we agree on the same file to test? It may be easier to start from a raw file and decode it so I might use a recent run from the "online" directory, or might even copy fresh data<br>
>><br>
>> I can run this on one of the clara machine tonight<br>
>><br>
>> Best regards<br>
>> FX<br>
>><br>
>> On Fri, Mar 2, 2018 at 8:13 PM, Vardan Gyurjyan <<a href="mailto:gurjyan@jlab.org">gurjyan@jlab.org</a>> wrote:<br>
>> Hi Silvester,<br>
>> I also notice that FTCAL and FTHODO services are making many dB accesses during the initialization. I expect to see a single access to the database followed by a single dB disconnect.<br>
>> -Vardan<br>
>><br>
>><br>
>> Sent from my iPhone<br>
>><br>
>> On Mar 2, 2018, at 7:50 PM, Sylvester J. Joosten <<a href="mailto:tuf42480@temple.edu">tuf42480@temple.edu</a>> wrote:<br>
>><br>
>>> Hi Rafaella, hi Vardan,<br>
>>><br>
>>> In case this is useful: I recognize this error in the context of accessing tables from CCDB from COATJAVA. If this happens when<br>
>>><br>
>>> if(this.entries.hasItem(index)<wbr>==false) (org.jlab.utils.groups.<wbr>IndexedTable)<br>
>>><br>
>>> fails. entries.hasItem() contains the following checks:<br>
>>><br>
>>> —> calls IndexedList.hasItem(int... index) (org.jlab.utils.groups.<wbr>IndexedList)<br>
>>> —> has 2 internal checks:<br>
>>> 1. if(index.length!=this.<wbr>indexSize)<br>
>>> 2. IndexGenerator.hashCode(index)<wbr>;<br>
>>><br>
>>> In my experience, this implies that there is some kind of issue or inconsistency when accessing CCDB, at least for this particular run.<br>
>>><br>
>>> Just my 2 cents.<br>
>>> Best,<br>
>>> Sylvester<br>
>>><br>
>>><br>
>>>> On Mar 2, 2018, at 7:37 PM, Vardan Gyurjyan <<a href="mailto:gurjyan@jlab.org">gurjyan@jlab.org</a>> wrote:<br>
>>>><br>
>>>> Hi Raffaella,<br>
>>>> I do not know what is exactly the cause but whenever I use one of these services in the data processing chain I get out memory exception. This exception is not recoverable. As I mention this happens every single time on clonfar0 node. I never saw this error on the farm machines though. May be FX can comment. I am getting these error on data over the ET as well as decoded files from FX’s decoded files directory.<br>
>>>> Vardan<br>
>>>> Sent from my iPhone<br>
>>>><br>
>>>> On Mar 2, 2018, at 4:53 PM, Raffaella De Vita <<a href="mailto:Raffaella.Devita@ge.infn.it">Raffaella.Devita@ge.infn.it</a>> wrote:<br>
>>>><br>
>>>>> Hi Vardan,<br>
>>>>> I'm the author of those services. The only change that was done recently was a modification of an hardcoded constant and, after that was done, FX cooked several files for FT studies. Nothing else was changed in more than one month. Anyway, I will try to reproduce the problem and debug it.What data are you processing?<br>
>>>>> Regards,<br>
>>>>> Raffaella<br>
>>>>><br>
>>>>> Vardan Gyurjyan wrote:<br>
>>>>>> Hi FX,<br>
>>>>>><br>
>>>>>> Since I am not sure who is the FTCAL and FTHODO engines author I am cc-ing this email to clas12.<br>
>>>>>> There is a critical bug introduced in these service engine’s code for the 5a.1.0 release. It is 100% reproducible on clonfarm0 node (online reconstruction node), where JVM crashes with the out of memory exception. Reconstruction chain without these services function properly.<br>
>>>>>> These are service engines that also print for every event warning messages such as “ [IndexedTable] ---> error.. entry does not exist” (I consider them warning since if this is a real error the processing should be stoped). Any ways, this is a serious bug that can result in large number of job failures on the farm.<br>
>>>>>><br>
>>>>>> -vardan<br>
>>>>>> ------------------------------<wbr>--------------------<br>
>>>>>> Vardan H. Gyurjyan, Ph.D.<br>
>>>>>> Staff Scientist<br>
>>>>>> Thomas Jefferson Accelerator Facility<br>
>>>>>> Newport News, VA, 23606<br>
>>>>>> E-mail: <a href="mailto:gurjyan@jlab.org">gurjyan@jlab.org</a><br>
>>>>>> <a href="tel:757-269-5879" value="+17572695879">757-269-5879</a> (JLAB)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> ______________________________<br>
>>>>>> _________________<br>
>>>>>> Clas12_software mailing list<br>
>>>>>><br>
>>>>>> <a href="mailto:Clas12_software@jlab.org">Clas12_software@jlab.org</a><br>
>>>>>> <a href="https://mailman.jlab.org/mailman/listinfo/clas12_software" rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/clas12_<wbr>software</a><br>
>>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Clas12_software mailing list<br>
>>>> <a href="mailto:Clas12_software@jlab.org">Clas12_software@jlab.org</a><br>
>>>> <a href="https://mailman.jlab.org/mailman/listinfo/clas12_software" rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/clas12_<wbr>software</a><br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Clas12_software mailing list<br>
>> <a href="mailto:Clas12_software@jlab.org">Clas12_software@jlab.org</a><br>
>> <a href="https://mailman.jlab.org/mailman/listinfo/clas12_software" rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/clas12_<wbr>software</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Clas12_software mailing list<br>
>> <a href="mailto:Clas12_software@jlab.org">Clas12_software@jlab.org</a><br>
>> <a href="https://mailman.jlab.org/mailman/listinfo/clas12_software" rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/clas12_<wbr>software</a><br>
> ______________________________<wbr>_________________<br>
> Clas12_software mailing list<br>
> <a href="mailto:Clas12_software@jlab.org">Clas12_software@jlab.org</a><br>
> <a href="https://mailman.jlab.org/mailman/listinfo/clas12_software" rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/clas12_<wbr>software</a><br>
<br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><clara_log></div></blockquote></body></html>