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.
The only "entity" here is a capture agent with a series of recordings in it. Then, the most logical scheme is to see (for state notification purposes) the agent as a container with its own state, with a certain number of recordings inside. And this is because the agent state is intimately linked to the state of their recordings, and if the agent fails to report somehow, its recordings are very likely to stop reporting, too. This dependence (in a single way, i.e. the recordings depend on the agent, and not vice-versa) should be clearly reflected in the state reporting scheme, but it isn't. Recordings and Agents seem completely independent items from a state reporting perspective. 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. 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. Best regards Rubén 2011/9/26 Judy Stern <[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]>> 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]>>> 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]>> > >>>> > >> 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 > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > Judy Stern > Educational Technology Services, UC Berkeley > [email protected] > > > > _______________________________________________ > 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
