Comments inline. 2011/9/27 Greg Logan <[email protected]>
> 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. Then why a simple data structure reports its state independently from: a) other data structures of its kind; and b) the agent which is actually doing the work? Why not link the recordings to the agent which is reporting their state? I just don't see the benefit. > 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? Sorry, I was not very clear. I meant that you cannot assign IDs locally in each capture agent because they're likely to collide with other agent's. This may be a matter of opinion, but I found more understandable having "the capture 5 in the agent X" than "the capture 43453453", and then having to guess which agent it belongs to. > > > 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. > Yes, I know. But while we should keep that in mind, it's also true that some endpoints are still changing to accomodate new needs or design changes. I won't #propose a change in the reporting structure, of course, because I don't think it's so urgent or will report so many benefits, but I do believe it's more logical and well-organized, and avoids the agents report recording states thousands of times when they could do it in a single call. > 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 > > > > _______________________________________________ > 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
