[Javalist] Jenkins: SVN: XML: Premature end of file

2014. Nov. 20., Cs, 23:36:20 CET

Jelenleg fizikai vason fut, de régebben amikor még nálunk is virtualizáltan
futott, voltak rejtélyes megszakadások.

2014. november 20. 23:27 Gábor Lipták írta, <gabor.liptak at gmail.com>:

> Szia!
>
> Mégegy ötletem van. Nálunk a build rendszer virtualizált környezetben fut
> (sajnos). Olyan fura networking és diszk hibák történnek néha, teljesen
> megmagyarázhatatlanul, hogy csak na. Ha a te környezeted is virtualizált,
> tégy próbát ha lehet fizikai vason. Hátha ott nincs baj.
>
> Üdv:
>
> Gábor
>
> 2014. november 20. 22:42 György Gajdics írta, <ggtech65 at gmail.com>:
>
> Sziasztok!
>>
>> A szál lezárásaként mondanám el a konklúziókat.
>>
>> Mivel az összes temp állomány létrehozását minősítettem a BUILD_TAG-gal
>> és a hiba ezután is előfordult, ebből nyilvánvaló lett (és Gábornak igaza),
>> hogy a minősítetlen temp megoldás is szál és jvm biztos volt és az SVN
>> klienssel van valami gond. Viszont a javasolt SVNkit-re rákeresve ugyanez a
>> hiba ott is előfordult, úgyhogy azt a szálat nem erőltettem tovább.
>>
>> A részleges megoldást az jelentette, hogy az összes "svn info --xml"
>> hívást lecseréltem --xml nélkülire (a kimenet regex-el feldolgozva). Ez
>> ~98%-ban megoldotta a problémát, egy-két esetben itt sem sikerült
>> kiértékelni az információt, ennek oka még homályos, de a kezelhető szintre
>> süllyedt a false pozitív hibaüzenetek száma. Közben a hiba - azért jóval
>> kisebb mértékben - áttevődött egy másik helyre ahol szintén xml lekérdezés
>> történik (svn stat --xml), de ennek megoldása ugyanaz lesz, mint az info
>> esetén.
>>
>> ui: A build rendszerrel van még egy kisebb fajsúlyú hiba, de arra inkább
>> majd egy új szálat indítok.
>>
>> 2014. október 28. 12:18 György Gajdics írta, <ggtech65 at gmail.com>:
>>
>>> Elfelejtettem mondani egy talán fontos dolgot. A CI szerver meg minden
>>> egyéb Windows-on (Windows Server 2008 R2 Standard) fut.
>>>
>>> Viszont éjszaka újrafordult a 300+ modul.
>>> Végül nem korlátoztam egy szálra végrehajtást, hanem kiegészítettem a
>>> temp állományokat egy job specifikus prefix-szel (sajnos egyelőre csak egy
>>> helyen):
>>>
>>> <tempfile destdir="${env.TEMP}" property="temp.file"
>>> *prefix="${env.BUILD_TAG}"* deleteonexit="true"/>
>>>
>>> Az eredmény sajnos nem túl rózsás. A false pozitív hibák száma nem
>>> csökkent, de néhány esetben áttevődött build script egy másik temp
>>> állományt használó részére, valamint most rég nem látott egyéb hibát is
>>> kaptam (ugyanott egyébként): "XML document structures must start and end
>>> within the same entity."
>>> Ebben az esetben az xml állomány csak részben jön létre, és így tényleg
>>> nem tudja betölteni.
>>>
>>> Olyan, mintha néhány (de azért elég sok) esetben az svn nem tudná kiírni
>>> a standard outputra az információkat elég gyorsan. Aztán van amikor egy bit
>>> sincs az állományban, van amikor megvan a fele. Az svn az ant exec
>>> task-jával van indítva (nincs parallel végrehajtás scripten belül).
>>>
>>>             <exec executable="${svn.svn}"
>>>                   failonerror="true"
>>>                   output="${temp.file}">
>>>                 <arg value="info"/>
>>>                 <arg value="--xml"/>
>>>                 <arg value="@{url}"/>
>>>                 <arg value="--username"/>
>>>                 <arg value="@{username}"/>
>>>                 <arg value="--password"/>
>>>                 <arg value="@{password}"/>
>>>             </exec>
>>>
>>> Ma még megpróbálom a prefix-et az összes temp-nél, aztán ha az sem
>>> segít, akkor jön az svnkit.
>>>
>>>
>>>
>>>
>>> 2014. október 27. 23:01 Gábor Lipták írta, <gabor.liptak at gmail.com>:
>>>
>>> Az ant tempfile simán a java.io.File.createTempFile-t használja. Lásd:
>>>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ant/ant/1.8.4/org/apache/tools/ant/util/FileUtils.java#FileUtils.createTempFile%28java.lang.String%2Cjava.lang.String%2Cjava.io.File%2Cboolean%2Cboolean%29
>>>>
>>>> A java.io.File.createTempFile pedig a securerandom miatt (
>>>> http://stackoverflow.com/a/4702630/337621) eléggé szál és több jvm
>>>> biztosnak tűnik nekem. Első ránézésre ez leginkább SVN kliens bugnak néz ki.
>>>>
>>>> Talán megpróbálhatnád SVNKittel. Egészen jól barátkozik Antallal. Lásd:
>>>> http://svnkit.com/kb/user-guide-ant.html
>>>>
>>>> 2014. október 27. 14:00 György Gajdics írta, <ggtech65 at gmail.com>:
>>>>
>>>> Ezt természetesen nem merném kijelenteni. Az ant generálja a nevet és 4
>>>>> végrehajtó szál lett beállva a master-en.
>>>>>
>>>>> <tempfile destdir="${env.TEMP}" property="temp.file"
>>>>> deleteonexit="true"/>
>>>>>
>>>>>
>>>>>
>>>>> 2014. október 27. 13:53 Auth Gábor írta, <auth.gabor at javaforum.hu>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> György Gajdics a következőt írta ekkor: 2014. október 27. 13:49:00
>>>>>> > A hiba egy ant scriptben dobódik, amely svn információt próbál
>>>>>> lekérni XML
>>>>>> > formában (svn info --xml url), az eredmény egy temp állományba
>>>>>> kerül,
>>>>>> > amelyet ant xmlproperty tölt be. Ez az utolsó pont az, ahol a hiba
>>>>>> > előfordul.
>>>>>>
>>>>>> A fájl neve ugye szálbiztosan egyedi és nem lehet olyan, hogy egy
>>>>>> másik szál
>>>>>> véletlenül bele tud írni?
>>>>>> --
>>>>>> Auth Gábor
>>>>>>
>>>>>> _______________________________________________
>>>>>> Javalist mailing list
>>>>>> Javalist at lists.javaforum.hu
>>>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Javalist mailing list
>>>>> Javalist at lists.javaforum.hu
>>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Javalist mailing list
>>>> Javalist at lists.javaforum.hu
>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20141120/2f0f762d/attachment.html>