Discussion :

[joel.drigo]

Salut,

Je suis en train de migrer une application de JavaSE 1.5 (Eclipse RCP 3.5) vers JavaSE 1.7 (Eclipse 3.8.2). Alors que la nouvelle version fonctionne sans problème sur Windows, en 32 bits, comme en 64 bits, la version buildée pour MacOSX et JDK 1.7 64bits cause une StackOverFlowError que je ne comprends pas. L'application n'a pas posé de problème similaire lorsqu'elle était buildée en JavaSE 1.5, sous Eclipse 3.5, que cela soit sous Windows 32bts, ou Macintosh 32bits, (java 1.5 ou java 1.6 installé sur la machine).

J'ai tenté différent paramètres de taille de stack (-Xss), 512K, 1Mo, 2Mo, et allant même jusqu'à 75Mo : j'obtiens toujours cette erreur. J'ai du mal à situer les conditions de l'erreur. Elle survient toujours dans un appel de socketRead0 dans SocketInputStream, initié dans la bibilothèque Apache HttpClient, à laquelle j'accède par l'intermédiaire d'une bibliothèque sur laquelle je n'ai pas la maîtrise, mais j'ai des milliers d'autres requêtes utilisant les mêmes classes et méthodes qui fonctionnent sans problème, et ce, pour charger quelques octets, comme pour charger quelques gigaoctets. J'ai cru constater que l'erreur survenait lors de tâches gérées par un ExecutorService, combinées avec une GUI SWT et AWT, un environnement, donc "fortement" threadé, mais d'autres composants d'interface similaires (utilisant le même composant de GUI SWT/AWT), et qui font des requêtes similaires (mais sans pool de threads), fonctionnent. D'autres composants avec pool de threads, mais sans GUI SWT/AWT fonctionnent. Enfin bref, différentes combinaisons de conditions, fonctionnent ou pas, sans qu'il soit évident de déterminer quel composant est responsable, ou quelle combinaison de composants.

Je suis en train d'expérimenter (à tâtons) différentes options de résolution ou contournement (comme upgrader la version de httpclient par exemple), mais je suis à la recherche d'idées de voies à explorer.

Pour information, voici l'une des stack traces que j'obtiens :

!ENTRY ERROR pool-6-Gallery image refresh fr.wedia.noheto.press.ui.view.stockpage::gallery-1 (fr.wedia.noheto.engine.ui.newbaskets.internal.GalleryImageRefresher:114) 2014-02-13 14:50:51,274[36470]!MESSAGE Cannot refresh item image
com.noheto.remote.interfaces.CommunicationException: Communication : java.lang.StackOverflowError null
    at com.noheto.remote.impl.client.Remotehandler.invoke(Remotehandler.java:412)
    at com.sun.proxy.$Proxy2.getMetas(Unknown Source)
    at com.noheto.remote.impl.client.ResourceManagerServiceImpl.getMetas(ResourceManagerServiceImpl.java:44)
    at com.noheto.remote.impl.common.ServerResource._getMetas(ServerResource.java:56)
    at com.noheto.remote.impl.common.ServerResource.isFile(ServerResource.java:78)
    at fr.wedia.noheto.engine.model.Resource.isFile(Resource.java:157)
    at fr.wedia.noheto.template.AbstractCompositionInstance.hasCompositionFile(AbstractCompositionInstance.java:870)
    at fr.wedia.noheto.template.AbstractCompositionInstance.getPreviewIcon(AbstractCompositionInstance.java:1162)
    at fr.wedia.noheto.engine.ui.newbaskets.renderer.DefaultGalleryItemRenderer$PreviewIconRefreshHandler.getImage(DefaultGalleryItemRenderer.java:61)
    at fr.wedia.noheto.engine.ui.newbaskets.internal.GalleryImageRefresher$1.run(GalleryImageRefresher.java:76)
    at fr.wedia.util.java.concurrent.SafeRunnableWrapper.run(SafeRunnableWrapper.java:28)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
    at fr.wedia.util.java.thread.DefaultThreadPoolFactory$1.run(DefaultThreadPoolFactory.java:108)
Cause :
java.lang.StackOverflowError
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:152)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
    at org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:506)
    at org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.java:431)
    at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.closeIfStale(MultiThreadedHttpConnectionManager.java:1313)
    at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:382)
    at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
    at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
    at com.noheto.remote.impl.client.Remotehandler.invoke(Remotehandler.java:396)
    at com.sun.proxy.$Proxy2.getMetas(Unknown Source)
    at com.noheto.remote.impl.client.ResourceManagerServiceImpl.getMetas(ResourceManagerServiceImpl.java:44)
    at com.noheto.remote.impl.common.ServerResource._getMetas(ServerResource.java:56)
    at com.noheto.remote.impl.common.ServerResource.isFile(ServerResource.java:78)
    at fr.wedia.noheto.engine.model.Resource.isFile(Resource.java:157)
    at fr.wedia.noheto.template.AbstractCompositionInstance.hasCompositionFile(AbstractCompositionInstance.java:870)
    at fr.wedia.noheto.template.AbstractCompositionInstance.getPreviewIcon(AbstractCompositionInstance.java:1162)
    at fr.wedia.noheto.engine.ui.newbaskets.renderer.DefaultGalleryItemRenderer$PreviewIconRefreshHandler.getImage(DefaultGalleryItemRenderer.java:61)
    at fr.wedia.noheto.engine.ui.newbaskets.internal.GalleryImageRefresher$1.run(GalleryImageRefresher.java:76)
    at fr.wedia.util.java.concurrent.SafeRunnableWrapper.run(SafeRunnableWrapper.java:28)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
    at fr.wedia.util.java.thread.DefaultThreadPoolFactory$1.run(DefaultThreadPoolFactory.java:108)

Merci par avance de votre attention et vos suggestions.

[joel.drigo]

J'ai trouvé la raison de mon problème : j'utilisais une ThreadPoolFactory personnalisée qui utilisait un paramétrage de stacksize arbitraire, qui ne suffisait pas pour le mac, en 1.7, mais qui ne posait pas de problème dans les autres cas. Sans ce paramètre (la valeur 0), tout fonctionne bien. Forcément, ça explique pourquoi le paramètre -Xss ne semblait avoir aucun impact.

[adiGuba]

Salut,


C'est intéressant à savoir : j'ignorais complètement que l'on pouvait changer la stackSize d'un thread !


a++

[joel.drigo]

En fait, la prise en compte de ce paramètre est dépendante de la plateforme. Il est manifestement ignoré sous Windows (quelque soit la version de Windows, de java, et en 32 bits comme en 64 bits). Je ne sais pas s'il était pris en compte sur Macintosh, parce qu'il y a dans notre ThreadPoolFactory, un hack pour que sous java 1.6, elle délègue la création des threads à une instance de DefaultThreadPoolFactory (Sinon jil y avait un crash lors de la création du thread dans la jvm apple), et que toutes les machines de production, donc les machines de test, sont installées avec java 1.6. Du coup, en passant en 1.7, la délégation n'était plus activée, et la création de thread était faite avec des valeurs par défaut, dont la stacksize, qui avait une valeur complètement stupide (et en plus incohérente avec les stack traces observées lors du StackOverflowError), valeur masquée par la fabrique de délégation.