Skip to main content

TimeShiftManager doesn't properly assign ResourceUsages when reusing TimeShiftWindows

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
3 replies [Last post]
raja2526
Offline
Joined: 2011-05-17

Hi,
Consider the following Scenario
1) Start a Buffering Request on Service A
2) Say the state of the Buffering Request A is changed to NOT_READY_TO_BUFFER after tuning due to SIRequestException: DATA_UNAVAILABLE
3) Cancellation the Buffering Request on Service A which performs
a) updateNIResourceUsages (by using a timer of 5 seconds)
b) updateForRemovedUses
20110524 16:25:54.088 DEBUG RI.Stack- 431603 [System-1] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: notifyTuneComplete (NI org.cablelabs.impl.davic.net.tuning.NetworkInterfaceImpl@c6de084f,ti 0xcbb8daa4,tune SUCCESSFUL,sync LOCKED,loc ocap://f=0x29a9e4c0.m=0x10)20110524 16:25:54.150 INFO RI.Stack- org.cablelabs.impl.service.SIRequestException: DATA_UNAVAILABLE
20110524 16:25:54.166 DEBUG RI.Stack- 431687 [pool-18] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: Could not create a PID map table from initial components (java.lang.IllegalArgumentException: Error retrieving SI for service ocap://f=0x29a9e4c0.0x4.m=0x10(org.cablelabs.impl.service.SIRequestException: DATA_UNAVAILABLE))
20110524 16:25:54.166 INFO RI.Stack- 431695 [pool-18] INFO timeshift.TimeShiftWindow - TSW 0xa25a715c: setStateAndNotify(): Changed from state TUNE_PENDING to NOT_READY_TO_BUFFER
20110524 16:25:54.463 DEBUG RI.Stack- 431970 [pool-15] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: ableToBuffer: FALSE (no PID Map)
20110524 16:25:55.041 DEBUG RI.Stack- 432571 [Thread-53] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: updateForRemovedUses: Removing use(s) NO USES for client TSWC 0x43c87acb:[nlist 1,ru org.cablelabs.impl.ocap.dvr.TimeShiftBufferResourceUsageImpl@-1503453892[id=11127133,prio=220,org.davic.net.tuning.NetworkInterfaceController,][br=org.cablelabs.impl.manager.recording.BufferingRequestImpl@31e9a29d,],tsw TSW 0xa25a715c:[service ServiceImpl344026808 (ocap://0x6e4) ,state NOT_READY_TO_BUFFER,tuner 2,tbst 331710ms,btsb none, nclients 1, TSC:[uses NO USES,res BUFFERING,mind 10,desd 110,maxd MAX_VAL]],constrain TSC:[uses NO USES,res NO USES,mind 10,desd 110,maxd MAX_VAL],1st tsb: none]
20110524 16:25:55.056 DEBUG RI.Stack- 432580 [Thread-53] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: updateForRemovedUses: current state is NOT_READY_TO_BUFFER/NOCOMPONENTS and no tuner uses remaining.

4) Aproximately after 5 seconds once again if the Buffering Request is made on Service A
5) TimeShiftManagerImpl will consider the TSW (of Service A as usableTSW) which has the NI
20110524 16:26:01.056 DEBUG RI.Stack- 438577 [Thread-133] DEBUG timeshift.TimeShiftManagerImpl - getTSWByEvaluation: considering TSW 0xa25a715c:[service ServiceImpl344026808 (ocap://0x6e4) ,state NOT_READY_TO_BUFFER,tuner 2,tbst 331710ms,btsb none, nclients 0, TSC:[uses NO USES,res NO USES,mind 0,desd 0,maxd MAX_VAL]]
20110524 16:26:01.072 DEBUG RI.Stack- 438591 [Thread-133] DEBUG timeshift.TimeShiftManagerImpl - getTSWByDuration.durationEvaluator: Found active TSW for use: TSW 0xa25a715c:[service ServiceImpl344026808 (ocap://0x6e4) ,state NOT_READY_TO_BUFFER,tuner 2,tbst 331710ms,btsb none, nclients 0, TSC:[uses NO USES,res NO USES,mind 0,desd 0,maxd MAX_VAL]]
20110524 16:26:01.072 DEBUG RI.Stack- 438595 [Thread-133] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: addClient: Prior constraints: TSC:[uses NO USES,res NO USES,mind 0,desd 0,maxd MAX_VAL]
20110524 16:26:01.072 INFO RI.Stack- 438596 [Thread-133] INFO timeshift.TimeShiftWindow - TSW 0xa25a715c: RAJ:: calculateConstraints() :: m_constraints.reservations 0
20110524 16:26:01.072 INFO RI.Stack- 438597 [Thread-133] INFO timeshift.TimeShiftWindow - TSW 0xa25a715c: RAJ:: calculateConstraints() :: m_constraints.uses 0
20110524 16:26:01.072 DEBUG RI.Stack- 438598 [Thread-133] DEBUG timeshift.TimeShiftWindow - TSW 0xa25a715c: addClient: New constraints: TSC:[uses NO USES,res BUFFERING,mind 10,desd 110,maxd MAX_VAL]
20110524 16:26:01.088 INFO RI.Stack- 438608 [Thread-133] INFO recording.BufferingRequestImpl - BR 0x437832ef: startBuffering: Got TSWC 0x95576b1d:[nlist 1,ru org.cablelabs.impl.ocap.dvr.TimeShiftBufferResourceUsageImpl@1043436964[id=11127133,prio=220,org.davic.net.tuning.NetworkInterfaceController,][br=org.cablelabs.impl.manager.recording.BufferingRequestImpl@437832ef,],tsw TSW 0xa25a715c:[service ServiceImpl344026808 (ocap://0x6e4) ,state NOT_READY_TO_BUFFER,tuner 2,tbst 331710ms,btsb none, nclients 1, TSC:[uses NO USES,res BUFFERING,mind 10,desd 110,maxd MAX_VAL]],constrain TSC:[uses NO USES,res BUFFERING,mind 10,desd 110,maxd MAX_VAL],1st tsb: none]
20110524 16:26:01.088 DEBUG RI.Stack- 438614 [Thread-133] DEBUG recording.BufferingRequestImpl - BR 0x437832ef: startBuffering: NOT_READY_TO_BUFFER org.cablelabs.impl.manager.recording.BufferingRequestImpl@437832ef
20110524 16:26:01.088 INFO RI.Stack- 438616 [Thread-133] INFO recording.BufferingRequestImpl - BR 0x437832ef: startBuffering: switching to m_wfTunedStateImpl.

The resource usages for the BR 0x437832ef is not updated due to the state (NOT_READY_TO_BUFFER) of usableTSW
// tswNeedsToBeTuned = (usableTSW.getState() == TimeShiftManager.TSWSTATE_IDLE);
20110524 16:26:01.103 INFO RI.Stack- 438625 [Thread-129] INFO timeshift.TimeShiftWindow - TSW 0xa25a715c: releaseUnusedResources: current state: NOT_READY_TO_BUFFER
20110524 16:26:01.103 INFO RI.Stack- 438620 [Thread-133] INFO recording.BufferingRequestImpl - BR 0x437832ef: changeState: org.cablelabs.impl.manager.recording.BufferingRequestImpl$WFTunedState@bf3971ec

6) and if we schedule the Second Buffering Request on Service B
20110524 16:26:01.119 DEBUG RI.Stack- 438652 [Thread-130] DEBUG timeshift.TimeShiftWindow - TSW 0xbe91b440: addClient: Prior constraints: TSC:[uses NO USES,res NO USES,mind 0,desd 0,maxd MAX_VAL]
20110524 16:26:01.150 DEBUG RI.Stack- 438672 [pool-9] DEBUG timeshift.TimeShiftWindow - TSW 0xbe91b440: reserveNIAndTune: Attempting to reserve a NI with ru org.cablelabs.impl.ocap.dvr.TimeShiftBufferResourceUsageImpl@-371056013[id=11127133,prio=220,org.davic.net.tuning.NetworkInterfaceController,][br=org.cablelabs.impl.manager.recording.BufferingRequestImpl@edb71a2,]
20110524 16:26:01.213 DEBUG RI.Stack- 438733 [pool-9] DEBUG timeshift.TimeShiftWindow - TSW 0xbe91b440: reserveNIAndTune: RESERVED an NI (tuner 1)
20110524 16:26:01.213 INFO RI.Stack- 438735 [pool-9] INFO timeshift.TimeShiftWindow - TSW 0xbe91b440: reserveNIAndTune: TUNING NI (1) to ocap://f=0x1d258c40.0x2.m=0x10

7) and the third one on Service C,
leads ArrayIndexOutOfBoundsException while prioritizing the contention because of step 5
20110524 16:26:01.572 DEBUG RI.Stack- 439096 [Thread-132] DEBUG timeshift.TimeShiftWindow - TSW 0x153420eb: addClient: Prior constraints: TSC:[uses NO USES,res NO USES,mind 0,desd 0,maxd MAX_VAL]
20110524 16:26:01.603 DEBUG RI.Stack- 439129 [pool-21] DEBUG timeshift.TimeShiftWindow - TSW 0x153420eb: reserveNIAndTune: Attempting to reserve a NI with ru org.cablelabs.impl.ocap.dvr.TimeShiftBufferResourceUsageImpl@910519724[id=11127133,prio=220,org.davic.net.tuning.NetworkInterfaceController,][br=org.cablelabs.impl.manager.recording.BufferingRequestImpl@ba2d1416,]
20110524 16:26:01.775 INFO RI.Stack- 439300 [pool-21] INFO timeshift.TimeShiftWindow - TSW 0x153420eb: reserveNIAndTune: NetworkInterface failed to reserve: java.lang.ArrayIndexOutOfBoundsException
20110524 16:26:01.791 WARN RI.Stack- 439317 [pool-21] WARN event.SystemEventManager - ErrorEvent[24000000,5/24/11 4:56 AM] java.lang.ArrayIndexOutOfBoundsException: null
java.lang.ArrayIndexOutOfBoundsException
at org.cablelabs.impl.manager.resource.RecordingRezMgr.prioritizeContention(RecordingRezMgr.java:155)
at org.cablelabs.impl.davic.net.tuning.NetworkInterfaceManagerImpl.forceRelease(NetworkInterfaceManagerImpl.java:909)
at org.cablelabs.impl.davic.net.tuning.NetworkInterfaceManagerImpl.reserveFor(NetworkInterfaceManagerImpl.java:488)
at org.davic.net.tuning.NetworkInterfaceController.reserveFor(NetworkInterfaceController.java:418)
at org.cablelabs.impl.davic.net.tuning.ExtendedNetworkInterfaceController.reserveFor(ExtendedNetworkInterfaceController.java:184)
at org.cablelabs.impl.manager.timeshift.TimeShiftWindow.reserveNIAndTune(TimeShiftWindow.java:630)

What is the best possible solution to handle in the above scenario?
What is the best possible solution to handle in the above scenario?
1) providing a new TSW instead of usableTSW in step 5?
Problem : The above solution demands the release of tuner
2) Adding Resource Usages in addClient()
Problem : The javadoc of NOT_READY_TO_BUFFER specifies that the TSW should not be attached for buffering
3) Releasing NI immediately once buffering is cancelled as the TSW cannot be buffered further

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cpratt
Offline
Joined: 2008-12-18

I believe I see the issue.

When the TimeShiftManager finds an already-tuned TSW it's not updating the RUs to reflect the newly-added client.

In this case, the second BR find a TSW with no clients. And when the new client is added, no uses are added. But since the TSW won't give up the NI (since the BR has a reservation), it can end up in resource contention with no ResourceUsages - which is what is causing the exception.

I think the fix is simply a matter of updating the NI resource usages when a tune isn't necessary. I'll open a bug on monday. Let me know if you concur or if you would rather open the bug. I can provide you a patch for testing monday.

raja2526
Offline
Joined: 2011-05-17

Hi,

Do we still need to add the resource usages and allow the TSW for buffering when the state of the BR is in NOT_READY_TO_BUFFER state?

The javadoc says not to do so.

/**
* TimeShiftWindow state: The TimeShiftWindow will be in this state when the
* TimeShiftWindow is tuned but not buffering and conditions do not support
* buffering. The TimeShiftWindow supports buffered playback, but not
* buffering, conversion, or live playback in this state. Attaching for
* buffering, recording, and live playback is not allowed in this state
.
*/
public static final int TSWSTATE_NOT_READY_TO_BUFFER = 5;

I have raised an IT482 for this issue.

cpratt
Offline
Joined: 2008-12-18

For those watching this forum topic, the issue with the ArrayIndexOutOfBounds exception has been addressed with RI change 20423.

To directly answer the above question: ResourceUsages on the associated NI should reflect both TSW reservations and "usages" (attachments). The bug was that the RUs weren't updated to reflect reservations added to already-tuned/recycled TimeShiftWindows. The contract in the JavaDoc above still applies.