Develop Reference

AWS SDK is throwing SdkClientException

I am attempting to retrieve a secret from aws secrets manager. My application can retrieve 3 / 4 secrets. When attempting to retrieve the 2nd secret, i get an interrupt exception. The code below is what i am using. I am unsure where to look or why this is happening. It consistently happens when attempting to retrieve the 2nd secret. I have verified that it exists in aws and that it contains the value i expect.
I am using the reativerse [https://github.com/reactiverse/aws-sdk] library in tandem with vert.x + aws sdk 2. Any help or pointers on where to look would be greatly appreciated. The exception i see and the code i have are written below.
java.util.concurrent.ExecutionException: software.amazon.awssdk.core.exception.SdkClientException
at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:159)
at io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100)
at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:157)
at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: software.amazon.awssdk.core.exception.SdkClientException
at software.amazon.awssdk.core.exception.SdkClientException$BuilderImpl.build(SdkClientException.java:98)
at software.amazon.awssdk.core.internal.http.AmazonAsyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonAsyncHttpClient.java:189)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.invoke(BaseAsyncClientHandler.java:271)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.doExecute(BaseAsyncClientHandler.java:213)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.lambda$execute$1(BaseAsyncClientHandler.java:91)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.measureApiCallSuccess(BaseAsyncClientHandler.java:277)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.execute(BaseAsyncClientHandler.java:74)
at software.amazon.awssdk.awscore.client.handler.AwsAsyncClientHandler.execute(AwsAsyncClientHandler.java:52)
at software.amazon.awssdk.services.secretsmanager.DefaultSecretsManagerAsyncClient.getSecretValue(DefaultSecretsManagerAsyncClient.java:1142)
... 8 more
Caused by: software.amazon.awssdk.core.exception.SdkInterruptedException
at software.amazon.awssdk.core.internal.http.InterruptMonitor.checkInterrupted(InterruptMonitor.java:40)
at software.amazon.awssdk.core.internal.http.pipeline.stages.ApplyTransactionIdStage.execute(ApplyTransactionIdStage.java:43)
at software.amazon.awssdk.core.internal.http.pipeline.stages.ApplyTransactionIdStage.execute(ApplyTransactionIdStage.java:29)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.AmazonAsyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonAsyncHttpClient.java:185)
... 16 more
private final SecretsManagerAsyncClient client = VertxSdkClient.withVertx(SecretsManagerAsyncClient.builder(), ctx).build();
public <T> Promise<T> getSecret(String secretName) {
Promise<T> completableFuture = Promise.promise();
Context ctx = Vertx.vertx().getOrCreateContext();
ctx.owner().executeBlocking(blockingFuture -> {
try {
GetSecretValueRequest valueRequest = GetSecretValueRequest.builder().secretId(secretName).build();
CompletableFuture<GetSecretValueResponse> valueResponse = this.client.getSecretValue(valueRequest);
GetSecretValueResponse getResponse = valueResponse.get();
String response = getResponse.secretString();
completableFuture.complete((T) Json.decodeValue(response, new <T>Object().getClass()));
blockingFuture.complete();
} catch (Exception e) {
// log exception.
}
});
...
}

See SdkInterruptedException ...it has one method getResponse():
try {
// provoke the exception in here
} catch (SdkInterruptedException e) {
System.err.println(e.getResponse());
}
This should (hopefully) at least tell why the request had been interrupted.
// log exception. is not the correct approach to handle any Exception.
The SdkClientException might be more relevant than the SdkInterruptedException:
try { ...
} catch (SdkClientException e) {
// log that exception, instead of ignoring it.
System.err.println(e.getMessage());
}
This is how an Authorization Header (AWS Signature Version 4) should basically look alike.
It may well be, that HMAC-SHA256 headers are being enforced (they're different on each single request). I could even provide a known to be working example... which would show how to configure the SecretsManagerClient. I'd suspect the root cause related to that client's configuration.
When I read "when attempting to retrieve the 2nd secret", this with high probability means that you need a refresh the HMAC-SHA256 signature before the second request will be performed. Destroying the client and constructing it again may be one sloppy workaround. When seeing duplicate values for AWS4-HMAC-SHA256 header on both requests, this definitely is the cause.

Apache CXF Policy: Security configuration could not be detected (external policies)

For a few days I try to resolve following issue:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Security configuration could not be detected. Potential cause: Make sure jaxws:client element with name attribute value matching endpoint port is defined as well as a ws-security.signature.properties element within it.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:158)
at com.sun.proxy.$Proxy38.getSignedDocument(Unknown Source)
at pl.mycompany.epuap.TPSigning_TPSigning_Client.main(TPSigning_TPSigning_Client.java:55)
Caused by: org.apache.cxf.ws.policy.PolicyException: Security configuration could not be detected. Potential cause: Make sure jaxws:client element with name attribute value matching endpoint port is defined as well as a ws-security.signature.properties element within it.
at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:315)
at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1851)
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:570)
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:149)
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:572)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:136)
... 2 more
This happens when I try to call webservice: https://pz.gov.pl/pz-services/tpSigning?wsdl with external (referenced) policy: https://pz.gov.pl/pz-services/tpSigning?wsdl=wssec-policies.wsdl.
Here is my code:
Properties properties = new Properties();
properties.put("org.apache.ws.security.crypto.provider", "org.apache.ws.security.components.crypto.Merlin");
properties.put("org.apache.ws.security.crypto.merlin.keystore.type",config.getKeystoreType());
properties.put("org.apache.ws.security.crypto.merlin.keystore.password",config.getKeystorePass());
properties.put("org.apache.ws.security.crypto.merlin.keystore.alias",config.getKeystoreAlias());
properties.put("org.apache.ws.security.crypto.merlin.file", config.getKeystoreFile());
outProps.put("cryptoProperties",properties);
outProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.TIMESTAMP + " " + WSHandlerConstants.SIGNATURE);
//outProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE);
outProps.put(WSHandlerConstants.USER, config.getKeystoreAlias());
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS, PasswordCallbackHandler.class.getName());
outProps.put(WSHandlerConstants.SIG_PROP_REF_ID,"cryptoProperties");
outProps.put(WSHandlerConstants.SIG_KEY_ID, "DirectReference");
outProps.put(WSHandlerConstants.SIGNATURE_PARTS, "{}{http://schemas.xmlsoap.org/soap/envelope/}Body");
WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
cxfEndpoint.getOutInterceptors().add(wssOut);
try{
String s = signing.addDocumentToSigning(doc, succesUrl, failureUrl, additionalInfo);
return s;
}
As I noticed, the policies aren't at all loaded by CXF engine. I tried to load policies by interceptors, but the effect is the same.
The probelm occurs also in 2.7.18 as in 3.x version.
Any help will be highly appreciated.
Regards
Mariusz

The problem is that you are mixing the "action" based approach to WS-Security, and the WS-SecurityPolicy driven approach. The WSDL you reference contains a security policy, and the CXF PolicyBasedWSS4JOutInterceptor will automatically take care of configuring security based on this. You just need to specify a few security configuration options, e.g. keystores. See here for more information: https://cxf.apache.org/docs/ws-securitypolicy.html

ServletUnit RequestDispatcher forward() / include() methods AbstractMethodError

I'm doing a java web app with a servlet and I wanted to write some tests to check its functionality (ex. authorization form). I hadn't been using any framework, just bare java in eclipse with tomcat 7.0
I've run into an error while trying to test authorization input. The app would check the login-password pair and then redirect using RequestDispatcher.forward() or RequestDispatcher.include() methods. But when executing them it throws an error with the following stack trace:
java.lang.reflect.Inv­ocationTargetExceptio­n
at su­n.reflect.NativeMetho­dAccessorImpl.invoke0­(Native Method)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke(­Unknown Source)
at su­n.reflect.DelegatingM­ethodAccessorImpl.inv­oke(Unknown Source)
at ja­va.lang.reflect.Metho­d.invoke(Unknown Sour­ce)
at en­tryPoint.Dispatcher.d­ispatch(Dispatcher.ja­va:166)
at en­tryPoint.Dispatcher.s­ervice(Dispatcher.jav­a:49)
at ja­vax.servlet.http.Http­Servlet.service(HttpS­ervlet.java:728)
at co­m.meterware.servletun­it.InvocationContextI­mpl.service(Invocatio­nContextImpl.java:76)
at co­m.meterware.servletun­it.ServletUnitClient.­newResponse(ServletUn­itClient.java:126)
at co­m.meterware.httpunit.­WebClient.createRespo­nse(WebClient.java:64­7)
at co­m.meterware.httpunit.­WebWindow.getResource­(WebWindow.java:220)
at co­m.meterware.httpunit.­WebWindow.getSubframe­Response(WebWindow.ja­va:181)
at co­m.meterware.httpunit.­WebWindow.getResponse­(WebWindow.java:158)
at co­m.meterware.httpunit.­WebWindow.updateWindo­w(WebWindow.java:199)
at co­m.meterware.httpunit.­WebWindow.getSubframe­Response(WebWindow.ja­va:183)
at co­m.meterware.httpunit.­WebWindow.getResponse­(WebWindow.java:158)
at co­m.meterware.httpunit.­WebClient.getResponse­(WebClient.java:122)
at te­st.Authorization.test­AuthCorrectInput_Wron­gPassword(Authorizati­on.java:102)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke0­(Native Method)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke(­Unknown Source)
at su­n.reflect.DelegatingM­ethodAccessorImpl.inv­oke(Unknown Source)
at ja­va.lang.reflect.Metho­d.invoke(Unknown Sour­ce)
at or­g.junit.runners.model­.FrameworkMethod$1.ru­nReflectiveCall(Frame­workMethod.java:45)
at or­g.junit.internal.runn­ers.model.ReflectiveC­allable.run(Reflectiv­eCallable.java:15)
at or­g.junit.runners.model­.FrameworkMethod.invo­keExplosively(Framewo­rkMethod.java:42)
at or­g.junit.internal.runn­ers.statements.Invoke­Method.evaluate(Invok­eMethod.java:20)
at or­g.junit.internal.runn­ers.statements.RunBef­ores.evaluate(RunBefo­res.java:28)
at or­g.junit.runners.Paren­tRunner.runLeaf(Paren­tRunner.java:263)
at or­g.junit.runners.Block­JUnit4ClassRunner.run­Child(BlockJUnit4Clas­sRunner.java:68)
at or­g.junit.runners.Block­JUnit4ClassRunner.run­Child(BlockJUnit4Clas­sRunner.java:47)
at or­g.junit.runners.Paren­tRunner$3.run(ParentR­unner.java:231)
at or­g.junit.runners.Paren­tRunner$1.schedule(Pa­rentRunner.java:60)
at or­g.junit.runners.Paren­tRunner.runChildren(P­arentRunner.java:229)
at or­g.junit.runners.Paren­tRunner.access$000(Pa­rentRunner.java:50)
at or­g.junit.runners.Paren­tRunner$2.evaluate(Pa­rentRunner.java:222)
at or­g.junit.internal.runn­ers.statements.RunBef­ores.evaluate(RunBefo­res.java:28)
at or­g.junit.internal.runn­ers.statements.RunAft­ers.evaluate(RunAfter­s.java:30)
at or­g.junit.runners.Paren­tRunner.run(ParentRun­ner.java:300)
at or­g.eclipse.jdt.interna­l.junit4.runner.JUnit­4TestReference.run(JU­nit4TestReference.jav­a:50)
at or­g.eclipse.jdt.interna­l.junit.runner.TestEx­ecution.run(TestExecu­tion.java:38)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.runTests(R­emoteTestRunner.java:­467)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.runTests(R­emoteTestRunner.java:­683)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.run(Remote­TestRunner.java:390)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.main(Remot­eTestRunner.java:197)
Caused by: javax.serv­let.ServletException:­ java.lang.AbstractMe­thodError: com.meterw­are.servletunit.Servl­etUnitServletContext.­getClassLoader()Ljava­/lang/ClassLoader;
at or­g.apache.jasper.servl­et.JspServlet.service­(JspServlet.java:343)
at ja­vax.servlet.http.Http­Servlet.service(HttpS­ervlet.java:728)
at co­m.meterware.servletun­it.RequestDispatcherI­mpl.forward(RequestDi­spatcherImpl.java:54)
at co­ntrollers.Auth.index(­Auth.java:78)
... 4­4 more
Caused by: java.lang.­AbstractMethodError: ­com.meterware.servlet­unit.ServletUnitServl­etContext.getClassLoa­der()Ljava/lang/Class­Loader;
at or­g.apache.jasper.compi­ler.TagPluginManager.­init(TagPluginManager­.java:72)
at or­g.apache.jasper.compi­ler.TagPluginManager.­apply(TagPluginManage­r.java:56)
at or­g.apache.jasper.compi­ler.Compiler.generate­Java(Compiler.java:24­0)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:373)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:353)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:340)
at or­g.apache.jasper.JspCo­mpilationContext.comp­ile(JspCompilationCon­text.java:646)
at or­g.apache.jasper.servl­et.JspServletWrapper.­service(JspServletWra­pper.java:357) ­
at or­g.apache.jasper.servl­et.JspServlet.service­JspFile(JspServlet.ja­va:390)
at or­g.apache.jasper.servl­et.JspServlet.service­(JspServlet.java:334)
... 4­7 more
The first block represents an invocation error caught by central controller (Dispatcher) servlet while invoking method in which an AbstractMethodError had been thrown. The second and third ones are about that error.
The code of the test method is as follows:
#Test
publi­c void testAuthIncorr­ectInput_Long() throw­s Exception {
W­ebRequest request = n­ew PostMethodWebReque­st("http://localhost:­8080/CenralReportDL/D­ispatcher?query=auth"­);
S­tring longString = ne­w String();
f­or (int i = 0; i < 52­; i++) {
­ longString­ += "aA_ba";
}
reque­st.setParameter("user­name", longString);
reque­st.setParameter("pass­word", longString);
W­ebResponse response =­ client.getResponse(r­equest);
a­ssertNotNull("No resp­onse received", respo­nse);
}
How can I get rid of this error? Is there a workaround? Should I maybe use some other means of servlet testing?
Also please do not suggest framework-specific testing utils such as strutstest, I want an actual solution for bare java web application.
UPDATE: In response to #JekinKalariya - I had a JasperException before. It complained about files not being in /WEB-INF folder, but due to my project structure they all were in /WebContent/WEB-INF. I was so frustrated because of that I just copied entire folder. Silly thing to do. I deleted it and now I'm back to that JasperException.
UPDATE: Now, I've done some research and found some answers on this issue. Didn't work for me though. I also found a suggestion to change a target runtime to J2EE Preview, which raised a different kind of exception:
com.meterware.httpuni­t.HttpNotFoundExcepti­on: Error on HTTP req­uest: 404 java.lang.C­lassNotFoundException­: org.apache.jasper.s­ervlet.JspServlet [http://localhost/WEB-­INF/jsp/auth.jsp]

Google Geocoding API returning illegalaccesserror

I sure hope you can help, I am getting towards the end of my rope. I posted this question yesterday but was quickly down-voted because I referred to what I was doing as Distance Matrix API and it was immediately assumed I had simply enabled the wrong API in google. I have now enabled many more APIs than I would ever need and am still getting the same IllegalAccessError:
May 06, 2015 12:48:16 PM com.google.maps.GeoApiContext setQueryRateLimit
INFO: Configuring rate limit at QPS: 10, minimum delay 50ms between requests
Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: tried to access class com.squareup.okhttp.Dispatcher from class com.google.maps.GeoApiContext
at com.google.maps.GeoApiContext.setQueryRateLimit(GeoApiContext.java:224)
at com.google.maps.GeoApiContext.setQueryRateLimit(GeoApiContext.java:210)
at com.google.maps.GeoApiContext.<init>(GeoApiContext.java:56)
at budgetrouting.MapPane.<init>(MapPane.java:27)
at budgetrouting.BudgetRouting$1.run(BudgetRouting.java:19)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Process exited with exit code 0.
My code:
GeoApiContext context = new GeoApiContext();
context.setApiKey(APIKey);
GeocodingResult[] results;
try {
results = GeocodingApi.geocode(context, "1600 Amphitheatre Parkway Mountain View, CA 94043").await();
System.out.println(results[0].formattedAddress);
} catch (Exception e) {
e.printStackTrace();
}
I have read every scrap of information on this error and how it relates to google api, but so far I don't have any definitive answers. I think that the fact that it is an error and not an exception means that it may not have anything to do with my access rights, especially since the error occurs the line before I set my API key. Since the definition of IllegalAccessError states "this error can only occur at run time if the definition of a class has incompatibly changed," I will include my dependencies:
google-maps-services-0.1.1.jar
okhttp-1.2.1-jar-with-dependencies.jar
I have checked okhttp for integrity and the class mentioned in the error does exist. I am using Oracle JDeveloper 12c. No Maven-type helper was used.
Just for completeness sake, these are the APIs I have enabled:
BigQuery API
Debuglet Controller API
Directions API
Distance Matrix API
Elevation API
Geocoding API
Google Cloud Logging API
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage JSON API
Google Maps Embed API
Google Maps Engine API
Time Zone API
Any ideas? Thanks!

The reason I was getting the above error was that google-maps-services-0.1.1.jar requires okhttp 2.0.0, not okhttp-1.2.1-jar-with-dependencies.jar, along with a few other things. This was a result of not using a Maven-like application.

I work with these libraries:
google-maps-services-0.1.1.jar -
okhttp-2.0.0.jar -
okio-1.11.0.jar -
Example code:
public String obtenerLatitudLongitud (String direccion) throws Exception{
try {
GeoApiContext context = new GeoApiContext().setApiKey(this.propiedades.get(ConstantesApi.KEY_MAPS_GOOGLE));
context.setQueryRateLimit(50);
GeocodingResult[] results = GeocodingApi.geocode(context,direccion).await();
latLong = results[0].geometry.location.toString();
logger.debug("Latitud, longitud : " + latLong);
} catch (Exception e) {
logger.error("Error Normalizando la direccion : " + direccion + " " + e.getMessage());
}
return latLong;
}

Wildfly: org.xnio.channels.FixedLengthOverflowException

Until now we used JBoss AS 7.1 which has a tomcat as front-server. We now upgraded to Wildfly (JBoss 8.0) which ships with undertow as a tomcat replacement.
For our filedownloads, we are reading the input stream of the file, and writing this to the external context's response output stream. This worked well in JBoss AS 7.1 - even for large files. In Undertow WE receive the following exception even for pretty "small" files:
13:04:43,292 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /project/getFile.xhtml}: java.lang.RuntimeException: org.xnio.channels.FixedLengthOverflowException
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.xnio.channels.FixedLengthOverflowException
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:97)
at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:137)
at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:172)
at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:580)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:614)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
... 9 more
The getFile.xhtml is invoking the download and the following code is used to copy the stream:
(Try, catch, logs and error handling removed to save some space)
public void downloadFile(FileEntity fileEntity) {
FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
ec.responseReset();
ec.setResponseContentType(getMimeType(fileEntity.getFile()));
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
ec.setResponseHeader("Content-Disposition", "attachment; filename=\"" + ConversionHelper.validateFilename(fileEntity.getDisplayFileName()) + "\"");
OutputStream output = ec.getResponseOutputStream();
FileInputStream fis = new FileInputStream(fileEntity.getFile());
IOUtils.copy(fis, output);
fc.responseComplete();
}
I noticed that removing the line
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
makes it work again. However the ResponseConentLength is "correct". Using
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue() + 9);
(note the +9) solves this. Using +8 -> FixedLengthOverflow, using +10 -> FixedLengthUnderflow
The +9 is independent of the filesize. Any idea? Looks strange to me...

If you call output.close() it should have the effect you are after. This looks like an issue with JSF, and not related to Undertow.

Found the problem.
It has to do with the change of the server engine. Just not sure if it is directly related to undertow, or more an error with wildfly / JSF (or if it was an error in Jboss and now is working correctly):
To invoke the download, we used something like this in the getFile.xhtml:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
</f:metadata>
<h:outputLabel value="#{getFileController.download()}" />
this would usually produce:
<label>value</label>
if the value of the label would be a string.
since we reset the response inside download(), <label> is removed again. Then, using a fixed response size that's equal the file-length and calling responseComplete() basically ommits the trailing </label>. Undertow however seems to ignore the responseComplete()-Call and tries to append </label> to the response, notices, that the end of the (fixed) response stream is reached, and therefore throws the mentioned exception.
That's why providing a size of +9 solves this error - but causes corrupt files, cause </label>\n will be appended to the file.
obviously the usage of an output label was bad practice there. But since we reseted and manually filled the response stream and called responseComplete() that was working fine.
the fix is obviously to not produce any (not required) html tags on that page:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
<f:event listener="#{getFileController.dlNow()}" type="preRenderView"></f:event>
</f:metadata>
Beside the bad design there - shouldn't call responseComplete() ommit any additional writing to the response stream, including any write ATTEMPTS?
The docu says:
Signal the JavaServer Faces implementation that the HTTP response for
this request has already been generated (such as an HTTP redirect),
and that the request processing lifecycle should be terminated as soon
as the current phase is completed.
So, if the Faces Implementation is told that the Response has been send - why would it try to append something?