[FLEX-15574] PlayerSession.waitForEvent() method causes a loss of events when used.

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Adobe Flex SDK 3.0 (Release)
• Fix Version/s: Adobe Flex SDK Previous
• Component/s: FDB - Debugger
• Environment: Affected OS(s): All OS Platforms; Affected OS(s): All OS Platforms; Browser: Firefox 2.x; Language Found: English
• Assignee: Adobe JIRA
• Reporter: Adobe JIRA
• Created: 05/Sep/08 15:55
• Updated: 15/Apr/11 15:27
• Resolved: 11/Sep/08 12:13

Description

Steps to reproduce:
1. write a flex app that emits a lot of trace statements regularly
2. code up a java program that debugs that flex app using the fdb API.
3. make use of Session.waitForEvent() to wait for debug events to process
4. log all trace events to the console

Actual Results:
many events are lost.

Expected Results:
all events get processed.

Workaround (if any):
None. I had to fix the PlayerSession.waitForEvent() method. The fixed version is attached.

ANALYSIS:

The current method code is:
public void waitForEvent() throws NotConnectedException, InterruptedException
{
Object eventNotifier = m_manager.getEventNotifier();
while(getEventCount() == 0 && isConnected())
{
synchronized (eventNotifier)

{ eventNotifier.wait(); }

}

// We should NOT call isConnected() to test for a broken connection! That
// is because we may have received one or more events AND lost the connection,
// almost simultaneously. If there are any messages available for the
// caller to process, we should not throw an exception.
if (nextEvent() == null && !isConnected())
throw new NotConnectedException();
}

The event loss is due to this final line of code:

if (nextEvent() == null && !isConnected())
throw new NotConnectedException();

That is, the nextEvent() call removes an event from the queue and throws it away.

As this code executes after the wait for a new event, in a normal run, almost all waitForEvent() calls will cause event losses.

The fix is to instead do:

if (getEventCount() == 0 && !isConnected())
throw new NotConnectedException();

I note that the DebugCLI class does not make use of waitForEvent(), but instead uses a "busy" sleep wait loop. That most likely explains why this bug was not caught before, as it is pretty fundamental.

While one is fixing things here, the wait loop should also be fixed to be proper, e.g., to guarantee the access to the eventNotifier lock in the critical section.

synchronized (eventNotifier)
{
while (getEventCount() == 0 && isConnected())

{ eventNotifier.wait(); }

}