Andreas, Sounds like an wrong behaviour because, even if the ingestion fails, the reception should be OK and the agent not bothered to send the file again, when a copy is already at the server. Can you file a bug in Jira?
Best regards Rubén 2011/10/25 <[email protected]> > Hi, > > just to close this thread: this issue is resolved on our side. > > Our solution is to use ha_proxy instead of Apache mod_proxy, and to set > the timeout to a really high value (currently 1 hour). > > Now the uploads work like charm, and we are glad it does :) > > The timeout has to be so high because the core apparently > 1. receives the media.zip ingest into opencast/files/collection/** > ingest-temp/ > 2. copies it to opencast/ingest/ > 3. unzips the file in this directory > 4. copies the unzipped files to opencast/files/mediapackage/<**id>/ > 5. cleans up > 6. and THEN sends back the OK to the client > > Greetings, Andreas > > [email protected] schrieb am Sat, 15 Oct 2011 betreff...": > > Hi, >> >> currently the most annoying issue we have here with our 8 CA / 1 Core MH >> 1.2 installation is that the media.zip-Files from the CA, if they exceed a >> certain size (something between 2-6GB, dunno), create a proxy error 502 >> when trying to ingest them to the core. >> >> 2011-06-16 12:02:39 INFO (IngestJob:52) - Proceeding to try ingestion >>> 2011-06-16 12:02:39 INFO (CaptureAgentImpl:740) - Ingesting recording: >>> 79c513e2-027c-4afb-993a-**8c497d220948 >>> 2011-06-16 12:07:35 ERROR (IngestJob:57) - Ingestion failed with a value >>> of 502 >>> >> >> This results in the client trying to ingest again and again and again, >> thus uploading more and more and more to the core and blocking the net for >> other things. >> >> I know this is a proxy problem, but I dont know what problem, so I write >> to this forum hoping that someone else might also have stumbled over the >> problem and can help me out with an advice where to look for to get this >> solved, ie. what to configure how to make the ingests work. >> >> The same error occurs bzw if I upload the files to the REST-Interface >> addZippedMediaPackage of the server manually, ie. via the use of the >> command: >> >> curl -v -s -H "X-Requested-Auth: Digest" --digest -u myaccount:mypass -F >> "[email protected]" http://mymatterhor.tuwien.ac.**at/ingest/** >> addZippedMediaPackage<http://mymatterhor.tuwien.ac.at/ingest/addZippedMediaPackage> >> >> One more thing to mention: the upload *works*, ie. the processing begins >> as it should, after files are uploaded, but the CA never knows of that >> because of the proxy error message. >> >> So, as always any input/experiences/advice welcome, in the hope that >> there is help available out there ;) >> >> Andreas >> >> [email protected] schrieb am Thu, 16 Jun 2011 betreff >> "Re:...": >> >> Date: Thu, 16 Jun 2011 17:41:35 +0200 (CEST) >>> From: [email protected] >>> To: Michael Roth <[email protected]> >>> Cc: [email protected] >>> Subject: Re: Matterhorn: upload der heutigen Mechanik-VO ? >>> >>> Hi Michael, >>> >>> ich weiss nicht, ob Du was damit anfangen kannst (ich nicht), aber der >>> Client hat heute in den Logs: >>> >>> 2011-06-16 12:02:39 INFO (IngestJob:52) - Proceeding to try ingestion >>> 2011-06-16 12:02:39 INFO (CaptureAgentImpl:740) - Ingesting recording: >>> 79c513e2-027c-4afb-993a-**8c497d220948 >>> 2011-06-16 12:07:35 ERROR (IngestJob:57) - Ingestion failed with a value >>> of 502 >>> >>> ... und das ganze ca. 13 mal. >>> >>> Fehler 502 ist laut >>> http://www.checkupdown.com/**status/E502.html<http://www.checkupdown.com/status/E502.html>irgendwas >>> mit "Bad gateway"; ich kenn mich aber zuwenig mit Netzwerk/Proxy >>> etc aus als da mehr darüber sagen zu können. >>> >>> Evt. kannst Du etwas damit anfangen, deswegen schick ichs mal. >>> >>> Lg, Andreas >>> >>> Michael Roth schrieb am Thu, 16 Jun 2011 betreff "Re: Matterhorn: >>> upload...": >>> >>>> Hallo Andreas, >>>> >>>> löschen kann man in Matterhorn nichts, einmal drinnen immer drinnen. >>>> Das mit dem Plattenplatz ist echt ein Problem, ich hab schon noch Platz >>>> nur wenn das so weitergeht haben wir in ein paar Monaten die gleichen >>>> Probleme wieder. >>>> >>>> Um den Plattenplatz zu vergrössern müsste ich den Server einmal neu >>>> starten, sollte aber in der Früh nicht wirklich stark auffallen. >>>> >>>> Nebenbei versuche ich noch das Upgrade auf Matterhorn 1.1 bzw. 1.2 >>>> hinzubekommen, Tatsache ist das es keine Upgrade Path gibt, das heißt alles >>>> Video müssen neu eingespielt werden. Hierzu gibt es zum Glück eine halbwegs >>>> gute Lösung, man kann die Mediapackage Files die von den Clients erzeugt >>>> werden einspielen, leider im Moment nur Theorie weil er bis jetzt immer mit >>>> einer Fehlmeldung abbricht. >>>> >>>> lg >>>> Michael >>>> >>>> Am 16.06.2011 13:41, schrieb [email protected]: >>>> >>>>> Hi Michi, >>>>> >>>>> super dass Du das wieder in den Griff bekommen hast; es sind nun 13 >>>>> "Jobs" zu Vorlesung 25 drin, aber es werden nicht mehr mehr. >>>>> >>>>> Wenn Du irgend einen Weg findest, die Jobs zu killen (bis auf einen), >>>>> sollte das OK sein, denk ich. >>>>> >>>>> Wie siehts mit dem Platz aus? Wurde der durch die vielen Jobs unnötig >>>>> in die Höhe gebracht? >>>>> >>>>> Herr Schmiedmayer/Mechanik wird noch 3 Vorlesungen halten, und jede >>>>> braucht >>>>> wie Du festgestellt hast, ca. 8 GB; geht sich das aus ? >>>>> >>>>> Wird es auch möglich sein, zur Konferenz Mitte Juli die nötigen 150GB >>>>> zur Verfügung zu stellen ? >>>>> >>>>> LG, Andreas >>>>> >>>>> >>>>> Michael Roth schrieb am Thu, 16 Jun 2011 betreff "Re: Matterhorn: >>>>> upload...": >>>>> >>>>>> Ich hab mal versucht die Matterhorn Software neu zu starten, das >>>>>> endete leider nicht so wie gedacht. >>>>>> Die Software startete nicht mehr, dann probierte ich die Postgres >>>>>> Datenbank, es schien so als ob diese aus welchen Grund auch immer hängen >>>>>> geblieben ist. DB neu gestartet, Matterhorn neu gestartet, jetzt schein >>>>>> es >>>>>> soweit wieder funktionieren. Irgendwie kommt mir der Server immer noch >>>>>> langsam vor, ich fürchte das Spiel beginnt von vorne und der Capture >>>>>> Client >>>>>> lädt weiterhin das Video wieder und wieder rein. >>>>>> >>>>>> >>>>>> Diese Situation ist alles andere als zufriedenstellend. >>>>>> >>>>>> lg >>>>>> Michael >>>>>> >>>>>> >>>>>> Am 16.06.2011 12:46, schrieb [email protected]: >>>>>> >>>>>>> ja, die heutige VO wird bereits 7mal parallel verarbeitet laut >>>>>>> Web-Interface; da dürfte was schiefgegangen sein, das sollte nicht so >>>>>>> sein, >>>>>>> oder ? Und es wird weiter upgeloaded, wenn man dem Web-Interface trauen >>>>>>> kann. >>>>>>> >>>>>>> LG, Andreas >>>>>>> >>>>>>> Michael Roth schrieb am Thu, 16 Jun 2011 betreff "Re: Matterhorn: >>>>>>> upload...": >>>>>>> >>>>>>>> Hallo, >>>>>>>> >>>>>>>> Platz ist noch ein wenig (8,8GB) da, jedoch ist der Server extrem >>>>>>>> belastet, teilweise durch Video Konvertierungen mit ffmpeg. >>>>>>>> >>>>>>>> lg >>>>>>>> Michael >>>>>>>> >>>>>>>> Am 16.06.2011 12:38, schrieb Andreas Johannes Krieger: >>>>>>>> >>>>>>>>> Lieber Michi, >>>>>>>>> >>>>>>>>> ich seh mir grad das MH-Server-Interface an, da versucht der >>>>>>>>> Client immer wieder die heutige VO immer wieder auf den Server >>>>>>>>> hochzuladen >>>>>>>>> ... liegt das wieder an einem Platzproblem ? >>>>>>>>> >>>>>>>>> LG, Andreas >>>>>>>>> >>>>>>>>> ----------------------- >>>>>>>>> [email protected] >>>>>>>>> 01/58801 DW 41523 >>>>>>>>> mobil: 0664/60 588 4523 >>>>>>>>> TU Wien >>>>>>>>> DVR-Nummer: 0005886 >>>>>>>>> ----------------------- >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------**------------------------------**-------------- >>>>>>>> Michael Roth email [email protected] >>>>>>>> Certified Project Management Associate http://www.zid.tuwien.ac.at/ >>>>>>>> **michael_roth/ <http://www.zid.tuwien.ac.at/michael_roth/> >>>>>>>> Red Hat Certified Technician >>>>>>>> Brandschutzwart gemäß TRVB O 117 >>>>>>>> Zentraler Informatikdienst (ZID) Tel. (++43-1) 588 01 - 42091 >>>>>>>> Technische Universitaet Wien Fax. (++43-1) 588 01 - 42099 >>>>>>>> Wiedner Hauptstr. 8-10, A-1040 Wien >>>>>>>> DVR-Nummer 0005886 >>>>>>>> >>>>>>>> >>>>>>> ----------------------- >>>>>>> [email protected] >>>>>>> 01/58801 DW 41523 >>>>>>> mobil: 0664/60 588 4523 >>>>>>> TU Wien >>>>>>> DVR-Nummer: 0005886 >>>>>>> ----------------------- >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> ------------------------------**------------------------------**-------------- >>>>>> Michael Roth email [email protected] >>>>>> Certified Project Management Associate http://www.zid.tuwien.ac.at/** >>>>>> michael_roth/ <http://www.zid.tuwien.ac.at/michael_roth/> >>>>>> Red Hat Certified Technician >>>>>> Brandschutzwart gemäß TRVB O 117 >>>>>> Zentraler Informatikdienst (ZID) Tel. (++43-1) 588 01 - 42091 >>>>>> Technische Universitaet Wien Fax. (++43-1) 588 01 - 42099 >>>>>> Wiedner Hauptstr. 8-10, A-1040 Wien >>>>>> DVR-Nummer 0005886 >>>>>> >>>>>> >>>>> ----------------------- >>>>> [email protected] >>>>> 01/58801 DW 41523 >>>>> mobil: 0664/60 588 4523 >>>>> TU Wien >>>>> DVR-Nummer: 0005886 >>>>> ----------------------- >>>>> >>>> >>>> >>>> -- >>>> ------------------------------**------------------------------** >>>> -------------- >>>> Michael Roth email [email protected] >>>> Certified Project Management Associate http://www.zid.tuwien.ac.at/** >>>> michael_roth/ <http://www.zid.tuwien.ac.at/michael_roth/> >>>> Red Hat Certified Technician >>>> Brandschutzwart gemäß TRVB O 117 >>>> Zentraler Informatikdienst (ZID) Tel. (++43-1) 588 01 - 42091 >>>> Technische Universitaet Wien Fax. (++43-1) 588 01 - 42099 >>>> Wiedner Hauptstr. 8-10, A-1040 Wien >>>> DVR-Nummer 0005886 >>>> >>>> >>> ----------------------- >>> [email protected] >>> 01/58801 DW 41523 >>> mobil: 0664/60 588 4523 >>> TU Wien >>> DVR-Nummer: 0005886 >>> ----------------------- >>> >> >> ----------------------- >> [email protected] >> 01/58801 DW 41523 >> mobil: 0664/60 588 4523 >> TU Wien >> DVR-Nummer: 0005886 >> ----------------------- >> > > ----------------------- > [email protected] > 01/58801 DW 41523 > mobil: 0664/60 588 4523 > TU Wien > DVR-Nummer: 0005886 > ----------------------- > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
