Affects: Release Notes project_key: JBPAPP6 Running a command from the CLI that generates too much data aborted with an error: [standalone@localhost:9999 /] /core-service=service-container:dump-services Communication error: java.util.concurrent.ExecutionException: Operation failed [disconnected /] The root cause is only logged at debug level in server.log: 16:12:15,887 DEBUG [org.jboss.as.protocol] (management-handler-thread - 7) active-op (1846420313) failed null: java.io.UTFDataFormatException: encoded string too long: 96453 bytes at java.io.DataOutputStream.writeUTF(DataOutputStream.java:347) [rt.jar:1.6.0_24] at java.io.DataOutputStream.writeUTF(DataOutputStream.java:306) [rt.jar:1.6.0_24] at org.jboss.as.protocol.mgmt.FlushableDataOutputImpl.writeUTF(FlushableDataOutputImpl.java:109) [jboss-as-protocol-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.dmr.StringModelValue.writeExternal(StringModelValue.java:46) [jboss-dmr-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.dmr.ModelNode.writeExternal(ModelNode.java:1476) [jboss-dmr-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.dmr.ObjectModelValue.writeExternal(ObjectModelValue.java:75) [jboss-dmr-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.dmr.ModelNode.writeExternal(ModelNode.java:1476) [jboss-dmr-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:116) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:295) [jboss-as-protocol-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:512) [jboss-as-protocol-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_24] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_24] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
Link: Added: This issue depends AS7-5491
Looking for some additional info here to prepare release notes: Is this issue for a specific command or all commands? Thanks, Eamon
Any command that returns a String that is over 64k bytes after converted to UTF-8.
Release Notes Text: Added: There is a known issue where any command that returns a String converted to UTF-8 that is over 64k is aborted with an error. The root cause of this is only logged at the debug level in server.log.
Release Notes Docs Status: Added: Documented as Known Issue
This is not exactly a CLI issue. It occurs in org.jboss.dmr.StringModelValue.writeExternal(StringModelValue.java:46). It's a limitation of the DataOutput.writeUTF(String).
Thanks Alexey, I will update the release notes accordingly.
Release Notes Text: Removed: There is a known issue where any command that returns a String converted to UTF-8 that is over 64k is aborted with an error. The root cause of this is only logged at the debug level in server.log. Added: There is a known issue where any command that returns a String converted to UTF-8 that is over 64k is aborted with an error. The root cause of this is only logged at the debug level in server.log. This issue occurs in org.jboss.dmr.StringModelValue.writeExternal(StringModelValue.java:46). It's a limitation of the DataOutput.writeUTF(String). The issue is currently under investigation.
Writer: Added: elogue
Release Notes Text: Removed: There is a known issue where any command that returns a String converted to UTF-8 that is over 64k is aborted with an error. The root cause of this is only logged at the debug level in server.log. This issue occurs in org.jboss.dmr.StringModelValue.writeExternal(StringModelValue.java:46). It's a limitation of the DataOutput.writeUTF(String). The issue is currently under investigation. Added: There is a known issue where any command that returns a String converted to UTF-8 that is over 64k is aborted with an error. The root cause of this is only logged at the debug level in `server.log`. This issue occurs in `org.jboss.dmr.StringModelValue.writeExternal(StringModelValue.java:46)` and is a limitation of the `DataOutput.writeUTF(String)` method. The issue is currently under investigation.
Release Notes Docs Status: Removed: Documented as Known Issue Writer: Removed: elogue Release Notes Text: Removed: There is a known issue where any command that returns a String converted to UTF-8 that is over 64k is aborted with an error. The root cause of this is only logged at the debug level in `server.log`. This issue occurs in `org.jboss.dmr.StringModelValue.writeExternal(StringModelValue.java:46)` and is a limitation of the `DataOutput.writeUTF(String)` method. The issue is currently under investigation. Docs QE Status: Removed: NEW
Verified for 6.1.DR4. Feel free to reopen this issue if needed.
Hi Jakub, Verified for 6.1.DR4 means issue is resolved in this version or still the issue exists. I am still facing this issue in JBOSS EAP 6.0 for JSP which is working fine in other servers like Weblogic without issue. So looks like problem is only with JBOSS Server. Thanks, Amit
It means that issue is resolved in 6.1.DR4.
Thanks Jakub, Can you please let me know its(6.1.DR4) JBOSS AS 7.2? Is it available for download to test my JSP? Thanks, Amit
Hi Jakub, Please let me know the link to download this version so that I can test for my application. Thanks, Amit
6.1 is an EAP version currently in development, it's based on AS 7.2 (unfortunately u will have to build it by yourself as it exist only in form of tag in git repository).
Hi Jacub, When this version is expected for release? I am not sure about how to buld from the repository. Also by any chance is there any patch available to fix this issue in EAP 6.0. Thanks, Amit
I'm afraid that issue tracker is not the right place to ask such question, it would be much more suitable for Customer Portal.
Documented as fixed bug in EAP 6.1.0 release notes.