Also can you look in the server log for any messages corresponding to the client exception? That may provide a better idea of what is going on.
Also can you share the XMLTABLE sql you are using? If it's written so that the processing is eligible for streaming the overhead of processing should be less.
Depending upon your version/logging level, the server should be logging something along the lines that the message is too large. There's current a fixed limit that the message must be smaller than 1mb. If you use a bind variable for the xml, then it will work as expected. Since something along these lines has come up before, I'll make sure that max message size is configurable and that the exception is logged as clearly as possible as it looks like other refinements in 8.6 now by default will just show the generic "unexpected exception" message without additional details.
> If you use a bind variable for the xml, then it will work as expected.
I should clarify if you use a lob bind value (a stream, clob, blob, or sqlxml) it will work. Otherwise with a string bind value you'll still see an exception.
[TEIID-2750] Improve handling of messages that are too large - JBoss Issue Tracker has been added to address this. It ensures proper server side logging. Increases the default max message size to 2 mb. Adds a system property to adjust the max message size. And allows for the exception to be communicated to the client without causing the connection to be dropped.