Hi Greg, sounds like a plan, and is basically what I was suggesting.
Tobias On 03.10.2012, at 17:56, Greg Logan <[email protected]> wrote: > On 12-10-03 09:51 AM, Tobias Wunden wrote: >> 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. > > Ok, fair enough. What about using JPA to store the mediapackage as > objects in the DB? This would prevent overflow from any column at, > perhaps, the cost of a hit on the DB and some serialization to/from the > XML itself. > > G > >> 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] >> _______________________________________________ > > > _______________________________________________ > 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] _______________________________________________
