On 11-09-26 03:02 PM, Rubén Pérez wrote: > I have always found so absurd that the recordings alone have the > capability to report their state independently from the capture agent > they live in, as if they were separate entities and (which is worse) at > the same hierarchical level.
Well... They are separate entities. Imagine if the CA was unable to access the network for a day, but was otherwise happy and healthy. It now has a backlog captures which it needs to update, along with the scheduled captures for a new day. This requires that the recordings and the CA be (more or less) at the same hierarchical level - they're just on different branches of the tree. Also, I would like to point out that the *CA* is what's sending the recording's state to the core, not the recording itself. The recording has no brains, it's just a data structure. > Not to mention that a hierarchical structure is much better in terms of > assigning IDs, since two recordings may have the same ID without > colliding, if they belong to different agents. Why on earth would we want to assign the same ID to multiple captures? What good does this bring, considering the extensive refactoring costs on both the core and the CA? > A xml-serialized Recording state is but a pair of fields indicating the > ID (perhaps the agent it belongs to) and the state. I don't see why an > agent state report cannot contain the state report for all the > recordings it contains. We are certainly sending much bigger xmls > through our endpoints without problems. True, but this upends what we've been talking about earlier in another thread: If we want to drive adoption (both commercial service providers and end-users) then we need to maintain steady endpoints. > Best regards > Rubén > > 2011/9/26 Judy Stern <[email protected] <mailto:[email protected]>> > > Taking this to the level of the admin UI, there seem to be a number > of use cases that call for users being able to see what capture > agents were used/are being used/will be used for what recordings > (and vice-versa). > At this point (in the UI) one can see the capture agents listed for > recordings in upcoming or capturing phases, but even there we can't > yet sort the capture agents column or search for specific capture > agents. And, of course, the Capture Agents tab should provide this > information. > > Related jira tickets: MH-2580, MH-7992, MH-2673, MH-3511 > > Judy > > > > On Sep 26, 2011, at 10:39 AM, Greg Logan wrote: > > > On 11-09-26 11:25 AM, Shane Phelan wrote: > >> Is there somewhere on the core then that you can see a list of > >> recordings for a particular agent? And what the status is? > > > > Not on a per-agent basis, at least not on the core. On the agent you > > can see this information at /state/recordings, but the core does not > > keep track of which recording comes from which agent. > > > >> I'm not sure if there is a problem at this point or not, but it is a > >> concern. Is there documentation somewhere of the capture agent > workflow > >> and the endpoints it uses? > > > > This is something that we need to work on. I know as a developer > which > > endpoints are in use, but there is no documentation that I know of > which > > lists them explicitly. In terms of the workflow this is somewhat > > deliberately vague. The core does not care how the recording is > > captured, only that it is. It presents a set of endpoints which any > > agent can integrate with, but the actual sequence of actions > inside the > > CA is left up to the implementation. > > > > G > > > >> Thanks again! > >> > >> -Shane > >> > >> On Mon, Sep 26, 2011 at 12:56 PM, Greg Logan <[email protected] > <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>>> wrote: > >> > >> On 11-09-26 10:43 AM, Shane Phelan wrote: > >>> Thanks Greg... but doesn't that become a resource issue that > every CA > >>> continues to send upload_finished to the Core for every video > that it > >>> has captured. Is there a mechanism that clears these out after some > >>> amount of time? Also what's the purpose it doesn't appear that > >> the Core > >>> does anything with the message because the video has already been > >>> ingested an processed. > >> > >> The agent stops sending the state for a given recording once > one of two > >> things happens: > >> > >> 1) If the agent runs low on disk space it begins removing the > oldest > >> ingested lectures, which also removes the state updates. > >> 2) If the recording is over a certain age (check > >> > > felix/conf/services/org.opencastproject.capture.ConfigurationManager.properties > >> for this value) the CA deletes its local cached copy, which > also removes > >> the state updates. > >> > >> We keep the recordings around on the CA so that (worst case) > you have > >> some leeway to recover lectures which somehow get lost or > damaged on the > >> core. Part of keeping them around, however, is keeping their > state up > >> to date. If this is causing issues please file a > bug/community feature > >> request. > >> > >> G > >> > >>> Thanks again, > >>> > >>> Shane > >>> > >>> On Mon, Sep 26, 2011 at 11:54 AM, Greg Logan > <[email protected] <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>> > >>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > >>> > >>> On 11-09-26 08:19 AM, Shane Phelan wrote: > >>>> I've done a few test captures with my CA and I'm curious why it > >>>> continues to send the following message over and over to the > >> Core. > >>> This > >>>> doesn't seem necessary. Is there a part of the process that is > >>> failing > >>>> that makes the CA think the Core doesn't know about the > >> uploaded file? > >>> > >>> Those are the normal state updates that the CA sends to the > >> core. Your > >>> logging level is set to debug which is why you are seeing so > >> many of > >>> these. You can either turn down the frequency of the updates (in > >>> > >> > > felix/conf/services/org.opencastproject.capture.impl.ConfigurationManager.properties) > >>> or change the logging level. > >>> > >>> G > >>> > >>>> 10:14:06 DEBUG (AgentStateJob:158) - #443 - Sending > >> recording 51's > >>>> state: upload_finished. > >>>> 10:14:06 DEBUG (AgentStateJob:193) - #443 - State push > >>>> org.opencastproject.capture.impl.jobs.AgentStateJob@6ae05134 to > >>>> http://10.8.104.89:8080/capture-admin/recordings/51 was > >> successful. > >>>> 10:14:06 DEBUG (AgentStateJob:158) - #443 - Sending > >> recording 25's > >>>> state: upload_finished. > >>>> 10:14:07 DEBUG (AgentStateJob:193) - #443 - State push > >>>> org.opencastproject.capture.impl.jobs.AgentStateJob@6ae05134 to > >>>> http://10.8.104.89:8080/capture-admin/recordings/25 was > >> successful. > >>>> 10:14:07 DEBUG (AgentStateJob:158) - #443 - Sending > >> recording 101's > >>>> state: upload_finished. > >>>> 10:14:07 DEBUG (AgentStateJob:193) - #443 - State push > >>>> org.opencastproject.capture.impl.jobs.AgentStateJob@6ae05134 to > >>>> http://10.8.104.89:8080/capture-admin/recordings/101 was > >> successful. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Matterhorn-users mailing list > >>>> [email protected] > <mailto:[email protected]> > >> <mailto:[email protected] > <mailto:[email protected]>> > >>> <mailto:[email protected] > <mailto:[email protected]> > >> <mailto:[email protected] > <mailto:[email protected]>>> > >>>> > >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >>> > >>> > >>> > >>> _______________________________________________ > >>> Matterhorn-users mailing list > >>> [email protected] > <mailto:[email protected]> > >> <mailto:[email protected] > <mailto:[email protected]>> > >>> <mailto:[email protected] > <mailto:[email protected]> > >> <mailto:[email protected] > <mailto:[email protected]>>> > >>> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Matterhorn-users mailing list > >>> [email protected] > <mailto:[email protected]> > >> <mailto:[email protected] > <mailto:[email protected]>> > >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >> > >> > >> > >> _______________________________________________ > >> Matterhorn-users mailing list > >> [email protected] > <mailto:[email protected]> > >> <mailto:[email protected] > <mailto:[email protected]>> > >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >> > >> > >> > >> > >> _______________________________________________ > >> Matterhorn-users mailing list > >> [email protected] > <mailto:[email protected]> > >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > _______________________________________________ > > Matterhorn-users mailing list > > [email protected] > <mailto:[email protected]> > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > Judy Stern > Educational Technology Services, UC Berkeley > [email protected] <mailto:[email protected]> > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > <mailto:[email protected]> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
