Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 2/3/20 2:10 PM, Peter Rader wrote: >> Does it ever work? > > Yes, I deployed and redeployed much larger WARs (i.e. 107MiB) many > times to the same instance. > >> >> The Tomcat manager has a default limit of 50MiB for uploads. Your >> WAR file it larger than that, so it might be failing. > > Some weeks ago I changed this default limit to "about" 500MiB - as > I always do (!!). To give you the 100% prove I send you the > max-file-size-config: > > 524288 > 524288 > 0 LGTM, though you might want to set file-size-threshold to something other than zero. 500MiB is a lot of wasted heap space to store a WAR file's contents :) Just to confirm: this is in the manager's WEB-INF/web.xml file? >> The /second/ upload in your log file might be because the >> deployer re-tries when the first attempt fails. > > Hm, if the plugin retries to upload I expect some logging output. > Even if there is no debug-output for the retry, I could try to > debug it locally. *shrug* >> It's so fast because Tomcat rejects the request immediately >> after looking at the Content-Length, instead of allowing 71MiB of >> stream over the network before rejecting the request. > > This can not be true, how would you tell the existance of this line > in the log?: > > 02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] > org.apache.catalina.core.ApplicationContext.log Manager: deploy: > Deploying web application 'XXX' Fair enough. > Anyway I found it by myself. ? >> On 2/2/20 4:48 PM, Peter Rader wrote: >>> The old version of the application had a daemon that have not >>> yet finished his execution. >> >> Tomcat cannot detect this situation, so it's unlikely to be the >> direct problem. > > I see. > >> How did you come to your conclusion? > > I noticed two hints that guides me to this idea: > > 1. I configured a user having the role manager-gui and tried to > stop the web-application using the manager-web-interface > (/manager/html/list). Stop command was not successfull, a error > message occoured above the application-table. What was the error? > 2. I could send the SHUTDOWN signal successfully, all looks like a > clear shutdown (the connectors successfully shutting down, CDI > shutdown, EntityManager closed, port 80+443 becomes free, sessions > passivated) but the java-process remains running for no reason and > must be killed manually. Well, that's no "no reason", but your application leaving a non-daemon thread running. This rarely if ever prevents a web application from stopping. You should really look at implementing a ServletContextListener to clean this up on application stop. In fact, that thread should be launched from the ServletContextListener on startup and shut-down in the same class for symmetry. If it's something like a Quartz timer (as it often is when this kind of thing is reported), then you might have to do some kind of initialization that you weren't already doing -- allowing Quartz to lazily auto-initialize -- so that you can properly shut it down, later. > 3. Last but not least, the original problem: The webapp fails to > redeploy using mvn tomcat:redeploy. Well, the failure to redeploy (actually, failure to deploy, right?!) isn't caused by your application's failure to stop, because, well: > 02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] > org.apache.catalina.core.ApplicationContext.log Manager: deploy: > Deploying web application 'XXX' Tomcat isn't in the business of deploying an application while there is still an application deployed with the same name (unless you are using parallel deployment, which is a different story, and you didn't mention that). So the problem is with the deployment, not the undeployment. Seeing two lines in the log file about PUT statements might just be due to a failure on the initial deployment. You didn't post the whole log file, so I can't be sure what is showing after the second "PUT" log. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44g0kACgkQHPApP6U8 pFhpxQ//bbjQdDYMmgVmwvF0CwVVmSGSFmNi4slpOX1Ib+HHomB+QTdzL5596vmA rzStPuQUQ7JrlZF40GKGEqTJo+zmvyk4G+PhJ1/cM1GMYvUI3UhdZTX2aELLzFRu hwn/02v/mxr4TwPegSSTcAskkmZZGA8/7852fWpN03CaFcSunLusXRCsarIK1b22 VF5gbH5ZkcMj6ZtqPNqG2phJQBlQe6bZnZ6GduEEF050IHTwLk/AT/L5qrr/4H32 +WAmd9aq8BE3GJC4bqGcqgCaWvE6gmTaVrN51bEKjEhM2RlyGTapfsMHz7X9Gpo5 QsqlzkyUYrOtoLV9O+XMiIVa147ujSwvInMpYCU9PJf9Q/0VmGk07TQDMNtL7EdH EXNx6kYXgo2NSiKJBniKUACCc2KGkRd4l67tlUN8JYZGTbp1BqVIuX95WIQ6R4q3 hxq3/J8bV+eTydoU+YP4q4nNrBo2L53UlhXhMqG+3e9nebdtPvSTMYBF+ewB3w8F m4YexEDmOIG7sfBnziWPOYCcEG3Uvxx2U1r7+3J/zrW6LOF8UmdMwB4bibk1AGgy MFLzUmr2lfDl4XQ9AAxrrnSfdkhs0NmjV8PIvPkn2RSW+XL166Js3wxoJiSb7jkX XILiQ5vPxxaMQ20+n4okc18RQLIPMneZC1am8X0UW7RKGYOLDMo= =GBhu -END PGP SIGNATURE- - To unsubscribe, e-mail:
Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
> Does it ever work? Yes, I deployed and redeployed much larger WARs (i.e. 107MiB) many times to the same instance. > > The Tomcat manager has a default limit of 50MiB for uploads. Your WAR > file it larger than that, so it might be failing. Some weeks ago I changed this default limit to "about" 500MiB - as I always do (!!). To give you the 100% prove I send you the max-file-size-config: 524288 524288 0 > > The /second/ upload in your log file might be because the deployer > re-tries when the first attempt fails. Hm, if the plugin retries to upload I expect some logging output. Even if there is no debug-output for the retry, I could try to debug it locally. > It's so fast because Tomcat > rejects the request immediately after looking at the Content-Length, > instead of allowing 71MiB of stream over the network before rejecting > the request. This can not be true, how would you tell the existance of this line in the log?: 02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application 'XXX' If - and only if - a WAR is rejected because of its size, the Manager would never ever write "Hey dude, I am deploying your web application XXX!". Right? Anyway I found it by myself. > On 2/2/20 4:48 PM, Peter Rader wrote: > > The old version of the application had a daemon that have not yet > > finished his execution. > > Tomcat cannot detect this situation, so it's unlikely to be the direct > problem. I see. > How did you come to your conclusion? I noticed two hints that guides me to this idea: 1. I configured a user having the role manager-gui and tried to stop the web-application using the manager-web-interface (/manager/html/list). Stop command was not successfull, a error message occoured above the application-table. 2. I could send the SHUTDOWN signal successfully, all looks like a clear shutdown (the connectors successfully shutting down, CDI shutdown, EntityManager closed, port 80+443 becomes free, sessions passivated) but the java-process remains running for no reason and must be killed manually. 3. Last but not least, the original problem: The webapp fails to redeploy using mvn tomcat:redeploy. > > - -chris -- Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SOLVED - Re: Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 2/2/20 4:48 PM, Peter Rader wrote: > The old version of the application had a daemon that have not yet > finished his execution. Tomcat cannot detect this situation, so it's unlikely to be the direct problem. How did you come to your conclusion? > Unfortuantely there is no further logging why the old version not > stoped yet. > > I expected to have the "mvn redeploy" waiting forever for this > deamon-locked problem. What I can not do is write a bug report > because the bug was inside my app. Why not? Are bugs in your application considered /features/? > But what I might do is to add a feature-request. Not sure where, > and not sure for what component, maven-tomcat-plugin maybe... What would the description be for the bug-report? "Please wait for all application-launched threads to complete before responding to the Maven plug-in's request top deploy a new version of my application"? All Tomcat does is wait for in-process requests to complete, then bring the application down, install the new one, and bring the new instance up. If you have a thread doing something else, Tomcat will not stop it, wait for it, or otherwise interrupt it (unless you have a ServletContextListener which waits for it to stop during shutdown, which you absolutely should be doing). - -chris NB: To Calder's point, you /did/ start another thread whether or not you realized it. Your "SOLVED" message(s) lack the proper SMTP headers[1] to get the messages properly threaded. It's not a big deal for real-time readers, but it's quite important for the mailing-list archives which are very valuable to people who have your same issue but aren't reading about it /today/. [1] https://cr.yp.to/immhf/thread.html -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44MKMACgkQHPApP6U8 pFiN6g/+LjIzNywFxgu6BLxjt0uMhA7p2XaZrmNzWf+zKEqNaISsoJmemiYNAlph 1xWMxiMOVD4a/kjRtdRdTXsHfacHg9i6jQdrc/4aYDR8FD22BHymsJgqpVpNfmrb eQrDcLSrx21kM5njlgHiS2K3NS6yjGmrGl0BrXfmHAenXbWPfck8s2SnU5E23Laf hFtwM3yy61Y7R4u/YC0SWA/NM4ynPrpCM08Ylujgcaw0fxCf8yXXNGluZPEBjB0L tP1lEwagv8wdFx0EOnKXwT9bFwgL6FNQcgk3RP94pkxw30HJ63gS7DLQ7FyvL0WN uPU5UjXw29sqk88oW3cWc/q8idwXlNXWvekoN4Avs3eXp+rPMJ/vH/oYO6gDKWjG kPtx+gwvffZqY0+lL/7ZPkjmmFMKskdkJMoOTOEcWYeii03cxXGsEz7KCf5oNEQD Jft8QzyIv+fVpO0GyUEqzi3mCaHvwKLQ+0DU2b96LYXx5zr5F3c4Gc+es6aH7Qlg o21+NG39BhSen9Y5eFObnONEtcXDh3F5udXgv5U+ExKYovZz81q1XnPvoAowGn3f fQbH2UxlW1vmTEeBZ+8H/pmUH4xi99V/b0svA3zfTkWND0/Y9cmW7YIjfDfnLP+C U50j52hrYqsYfd72YS0nJIEjnAcJ0z1ywtatH5xx7QXETurRWMY= =LMkr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 2/2/20 11:31 AM, Peter Rader wrote: > Hi, > > I am using maven to redeploy a application. > > Maven returning: [ERROR] Failed to execute goal > org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy (default-cli) on > project xxx: Cannot invoke Tomcat manager: Error writing to server > -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: > Failed to execute goal > org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy (default-cli) on > project XXX: Cannot invoke Tomcat manager at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec t > (LifecycleModuleBuilder.java:117) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec t > (LifecycleModuleBuilder.java:81) at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThrea dedBuilder.build > (SingleThreadedBuilder.java:56) at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) at > org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at > org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at > org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at > org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at > org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at > org.apache.maven.cli.MavenCli.main (MavenCli.java:193) at > sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) at > java.lang.reflect.Method.invoke (Method.java:498) at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) at > org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) at > org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) Caused by: > org.apache.maven.plugin.MojoExecutionException: Cannot invoke > Tomcat manager at > org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute > (AbstractCatalinaMojo.java:149) at > org.codehaus.mojo.tomcat.AbstractWarCatalinaMojo.execute > (AbstractWarCatalinaMojo.java:70) at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec t > (LifecycleModuleBuilder.java:117) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec t > (LifecycleModuleBuilder.java:81) at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThrea dedBuilder.build > (SingleThreadedBuilder.java:56) at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) at > org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at > org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at > org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at > org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at > org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at > org.apache.maven.cli.MavenCli.main (MavenCli.java:193) at > sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) at > java.lang.reflect.Method.invoke (Method.java:498) at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) at > org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) at > org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) Caused by: java.io.IOException: Error writing > to server at > sun.net.www.protocol.http.HttpURLConnection.writeRequests > (HttpURLConnection.java:700) at > sun.net.www.protocol.http.HttpURLConnection.writeRequests > (HttpURLConnection.java:712) at > sun.net.www.protocol.http.HttpURLConnection.getInputStream0 > (HttpURLConnection.java:1591) at > sun.net.www.protocol.http.HttpURLConnection.getInputStream > (HttpURLConnection.java:1498) at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream >
Aw: Re: SOLVED - Re: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
> Please post updates to the original thread. This is the original thread. > As suggested in the original thread, it was a permissions issue ... > permission denied because the port was already in use : ) Why do you think it is a permission issue? I already disproved that! How can you break it down to port-already-in-use? I found the answer and it was faar away from any permission issue! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SOLVED - Re: Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
On Sun, Feb 2, 2020, 15:49 Peter Rader wrote: > The old version of the application had a daemon that have not yet finished > his execution. > > Unfortuantely there is no further logging why the old version not stoped > yet. > > I expected to have the "mvn redeploy" waiting forever for this > deamon-locked problem. What I can not do is write a bug report because the > bug was inside my app. But what I might do is to add a feature-request. Not > sure where, and not sure for what component, maven-tomcat-plugin maybe... > > Please post updates to the original thread. As suggested in the original thread, it was a permissions issue ... permission denied because the port was already in use : )
SOLVED - Re: Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
The old version of the application had a daemon that have not yet finished his execution. Unfortuantely there is no further logging why the old version not stoped yet. I expected to have the "mvn redeploy" waiting forever for this deamon-locked problem. What I can not do is write a bug report because the bug was inside my app. But what I might do is to add a feature-request. Not sure where, and not sure for what component, maven-tomcat-plugin maybe... Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
Thank you for your reply. > Always look for the last "Caused by" in a stack trace for root cause. An > "IOException: Error writing to server" is indicative of a permissions > issue - I would start there, possibly the user account running the process. As pointed out in No. 3 the log said that the permission has been granted successfully. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mvn redeploy - double redeployment problem (within 0.2 seconds)
On Sun, Feb 2, 2020, 10:31 Peter Rader wrote: > Hi, > > I am using maven to redeploy a application. > > Maven returning: > [ERROR] Failed to execute goal > org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy (default-cli) on project > xxx: Cannot invoke Tomcat manager: Error writing to server -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy (default-cli) on > project XXX: Cannot invoke Tomcat manager > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot invoke > Tomcat manager > at org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute > (AbstractCatalinaMojo.java:149) > at org.codehaus.mojo.tomcat.AbstractWarCatalinaMojo.execute > (AbstractWarCatalinaMojo.java:70) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347) > Last "Caused by" Caused by: java.io.IOException: Error writing to server > at sun.net.www.protocol.http.HttpURLConnection.writeRequests > (HttpURLConnection.java:700) > at sun.net.www.protocol.http.HttpURLConnection.writeRequests > (HttpURLConnection.java:712) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream0 > (HttpURLConnection.java:1591) > at
