United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6943350 Intermittent "No registered plugin for applet ID x" errors in applet
JDK-6943350 : Intermittent "No registered plugin for applet ID x" errors in applet

Details
Type:
Bug
Submit Date:
2010-04-13
Status:
Closed
Updated Date:
2011-07-19
Project Name:
JDK
Resolved Date:
2011-06-01
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u19,6u20,6u20-rev
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_19"
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Client VM (build 16.2-b04, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Attached seperatly

A DESCRIPTION OF THE PROBLEM :
SUMMARY:

When running an applet that uses with the next generation plugin, intermittent errors occur. The errors appear to be caused by internal Java plugin code. The same error occurs with multiple users using the same software that uses applet deployment and this bug report is based on information found during internal investigation of the problem.

A typical stack trace is as follows (note that getting the stack trace requires increasing Java console trace level to 5):

---
network: Connecting https://host.com/path/to/servlet/com.company.server.Servlet?param=value with proxy=DIRECT
network: Connecting http://host.com:443/ with proxy=DIRECT
com.sun.deploy.net.cookie.CookieUnavailableException: No registered plugin for applet ID 3
	at sun.plugin2.main.client.MessagePassingExecutionContext.doCookieOp(Unknown Source)
	at sun.plugin2.main.client.MessagePassingExecutionContext.getCookie(Unknown Source)
	at sun.plugin2.main.client.PluginCookieSelector.getCookieFromBrowser(Unknown Source)
	at com.sun.deploy.net.cookie.DeployCookieSelector.getCookieInfo(Unknown Source)
	at com.sun.deploy.net.cookie.DeployCookieSelector.get(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.setCookieHeader(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
	at com.company.client.Client(Unknown Source)
	at com.company.client.Gui.mouseReleased(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
---

The applet is deployed with the following tag:

---
<applet
	name="Client" codebase="https://host.com/path/to/"	archive="client.jar" code="com.company.client.Client.class" mayscript="true">
	<param name="cache_archive" value="client.jar">
	<param name="java_arguments" value="-Dsun.java2d.noddraw=true">
</applet>
---

BACKGROUND:

The applet start fine, but later fails because it relies on data retrieved from deployment server using a HTTPS connection and this data retrieval fails so the applet can't work properly. Closer investigation of the problem on server side shows that session information (that is communicated using a cookie) is missing for requests from the failing applet client. For these requests, method HttpServletRequest.getSession().isNew() always returns true even if a new session cookies is set.

After setting client trace level to 5 a stacktrace is shown in the Java console. The stacktrace is listed above. Even after the error occurs, some other tasks requiring applet/browser-communication work, i.e JSObject-based Javascript execution works.

Once the problem occurs, it will repeat with further HTTPS requests. The only solution is to close the browser and start a new applet. At the moment the problem only repeats in a production environment using HTTPS communication so we do not know it also occurs with plain HTTP.

The problem occurs only intermittently, but it does not appear completely random since some users experience it more often than others and all users are not affected at all.

The exact same applet deployment tag, applet client and server side code has worked previously which together with the stack trace points to a regression bug in the applet plugin.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
As the bug is intermittent and for us only repeats in a closed production environment, proper step-by-step instructions are unavailable.

Basically:
1. Deploy an applet using a applet tag and the 1.6.0_19 plugin
2. Set the applet console trace level to 5
3. Have the applet communicate with a server using HTTPS (or HTTP)
4. Set a cookie on the server side
5. Use the same cookie for further communication
6. Repeat until error occurs

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Normal communication, cookie sent properly with each request, no exceptions thrown.
ACTUAL -
Communication fails, cookie missing from request, exception thrown (com.sun.deploy.net.cookie.CookieUnavailableException: No registered plugin for applet ID 3).

ERROR MESSAGES/STACK TRACES THAT OCCUR :
network: Connecting https://host.com/path/to/servlet/com.company.server.Servlet?param=value with proxy=DIRECT
network: Connecting http://host.com:443/ with proxy=DIRECT
com.sun.deploy.net.cookie.CookieUnavailableException: No registered plugin for applet ID 3
	at sun.plugin2.main.client.MessagePassingExecutionContext.doCookieOp(Unknown Source)
	at sun.plugin2.main.client.MessagePassingExecutionContext.getCookie(Unknown Source)
	at sun.plugin2.main.client.PluginCookieSelector.getCookieFromBrowser(Unknown Source)
	at com.sun.deploy.net.cookie.DeployCookieSelector.getCookieInfo(Unknown Source)
	at com.sun.deploy.net.cookie.DeployCookieSelector.get(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.setCookieHeader(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
	at com.company.client.Client(Unknown Source)
	at com.company.client.Gui.mouseReleased(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
Using an alternate communication / session management method would circumvent the problem it is not realistically possible. Closing the browser and launching a new applet resolves the issue temporarily, but repeated errors make applet use very difficult.

Release Regression From : 6u10
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

                                    

Comments
EVALUATION

Forward ported fix from 6 update to address the following:

When Plugin2Manager's stop() has executed completely, applet's stop() and destroy() too have been invoked, but the applet's appContext is not disposed because of classloader cache, it is just removed from the classloader cache
and it is waiting to be disposed when the reference to the classloader becomes zero.
In this case, getCurrentManager() of Plugin2Manager returns wrong manager. This started happening since 6u18 due to the fix for 6857855.

The fix checks if the manager obtained from ThreadLocal is already stopped, if it is then get manager from AppContext using getFromAppContext().
                                     
2011-05-05



Hardware and Software, Engineered to Work Together