Hi Andreas, just a wild guess but it may be that the failure is due to the mediapackage xml being sent to the distribution service, with the mediapackage xml being too large for the POST. Apache to my knowledge does not have such a limit, but Jetty (which is being used by Matterhorn internally) does.
That being said, it is (at least to me) unclear what possible ways are to get around that limit. First of all I found [1], but since we don't directly configure Jetty it may be difficult to apply that configuration parameter (you could try a -Dorg.eclipse.jetty.server.Request.maxFormContentSize= 200000 on the commandline when starting Matterhorn). Ideally, we would stop sending the full mediapackage and instead send mediapackage urls. Tobias On 21.11.2012, at 22:27, Andreas Krieger <[email protected]> wrote: > Hi, > > we have MH 1.3.1 with 1 admin (all services), 1 engage (media distribution = > local download and local streaming) downloads, and 1 worker (all services but > media distribution) up and running here. > > Thinks go quite fine, but we seem to push limits with highly segemented > videos. > > I've tried 3 times now, always the same result: a recording, that shows 190 > segments after the segmentation service, completely hangs in the streaming > distribution service with the following symptoms in both admin-log and > engage-log: > > ... > 2012-11-21 20:50:00 INFO (DistributeWorkflowOperationHandler:115) - > Distributing 'attachment-180' to the local repository > ... > 2012-11-21 20:51:03 INFO (DownloadDistributionService:175) - Distributing > attachment-180 to > /opt/matterhorn/distribution/downloads/44ec02a2-2d05-11e2-ad2c-00190f04fc8a/attachment-88/Screen.jpg > 2012-11-21 20:51:03 INFO (DownloadDistributionService:192) - Finished > distribution of > http://mh-admin.ltcc.tuwien.ac.at/files/mediapackage/44ec02a2-2d05-11e2-ad2c-00190f04fc8a/attachment-180/screen.jpg > ... > THEN AGAIN! > ... > 2012-11-21 20:51:13 INFO (DistributeWorkflowOperationHandler:115) - > Distributing 'attachment-180' to the local repository > ... > > AND THEN immediatelly: > 2012-11-21 20:51:22 WARN (ServiceRegistryJpaImpl:1410) - Service > org.opencastproject.distribution.streaming@http://mh-engage.at.tuwien.at > failed (500) accepting Job {id:2804576, version:2} > 2012-11-21 20:51:22 WARN (ServiceRegistryJpaImpl:1410) - Service > org.opencastproject.distribution.streaming@http://mh-admin.at.tuwien.at > failed (500) accepting Job {id:2804576, version:3} > ... (repeat the last 2 messages for every distribute job, and then again and > again, withoutever stopping). > > ... which essentially stops the server from doing anything useful. > > The only way to stop that was to remove the jobs from the database. But the > recording fails, no way to > > So, my question: can anyone explain that behaviour or point me to a fix? I'll > file this as a bug as soon as I see it again. > > Regards, Andreas > ----------------------- > BSc [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
