Hi Greg, as discussed during the meeting, it may or may not be a good idea to move the mediapackage xml out of the database. The idea of it being in there is that the mediapackage is an argument to the 'start workflow' operation, and the service registry and its job dispatching facility stores the arguments for service calls in the database so there can be failover. If we now move the mediapackage out of the db onto the filesystem and replace the db entry with a file:// or http:// url instead, job dispatching can be completely broken by cleaning up the working file repository or random places on disk.
>From my point of view, this suggest investigating whether there is a datatype >that is better suited such as a BLOB or anything similar, since Matterhorn >only uses the field for later reference, not for querying, searching or the >like. Tobias On 29.09.2012, at 00:02, Greg Logan <[email protected]> wrote: > Hi folks, > > I have a question for those familiar with the job architecture: Why do > we store the mediapackage xml in the jobs table? Why not a link to the > file in the filesystem? I have multiple captures here which overflow > the payload column during distribution. Everything else works, just > this particular piece of media appears to have a lot of scenes. I am > uncomfortable changing the segmentation settings since they obviously > work fine as is. I'm processing this lecture instead as a > presenter/source to avoid the scene detection, but this is an extremely > wasteful workaround. > > I'm tempted to propose that we should move that file onto disk where it > belongs in 1.5, but I'm not familiar enough with the jobs architecture > to say for sure. Could those who are more familiar with it (Tobias? :)) > chime in and give me a hint of how much work is going to be involved here? > > Thanks, > > G > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
