Other option would be that you are just using old version of client libs,
they should be updated to match ones used in WildFly
On Wed, Jun 29, 2016 at 5:15 PM, David M. Lloyd <david.lloyd(a)redhat.com>
wrote:
JBoss Remoting uses a feature called "HTTP Upgrade", which
basically
allows a client to connect to an HTTP port and then send a special HTTP
request which allows an "upgrade" to another arbitrary protocol. Later
versions of WildFly use this feature by default to reduce the count of
bound ports.
What is probably happening is that you are connecting to a port that has
a plain Remoting listener on it, but the client is using "http-remoting"
which means "JBoss Remoting over HTTP Upgrade". So the client sends an
HTTP request, but the server interprets it as garbage because it is
expecting a Remoting framed packet instead.
The fix is to either change the client from "http-remoting" to just
"remoting", or to change your server to use HTTP upgrade instead.
Information on this should be in the user docs.
On 06/29/2016 10:08 AM, Marlow, Andrew wrote:
> Hello everyone,
>
> This is an appeal for help to resolve the error JBREM000200 that I get
> when a process connects to wildfly to do some JMS work. Details follow:-
>
> I am trying to switch from JBoss-as-7.1.1.Final to Wildfly 9.0.1.Final.
> My project runs on Microsoft Windows and Red Hat Linux (RHEL 5.11). I am
> using java jdk 1.8.0_60. The switch to wildfly worked fine on Windows,
> once I found out what the config file changes were, especially the
> switch from remote port 4777 to undertow http port 8080. However, on
> linux the wildfly server get an error as soon as one of my processes
> connects to it. The wildfly log is not very busy. Wildfly starts with
> not much logged then I get a one line error report for every connection
> attempt:
>
> 2016-06-29 15:09:09,555 ERROR [org.jboss.remoting.remote.connection]
> (default I/O-6) JBREM000200: Remote connection failed:
> java.io.IOException: XNIO000804: Received an invalid message length of
> 1195725856
>
> The log of the process that connects contains a bit more detail:
>
> Error: NamingException detected during EndPointFactory JMS Server queue
> initialisation: Failed to connect to any server. Servers tried:
> [http-remoting://<myIpAddress>:8180 (java.io.EOFException: XNIO000812:
> Connection closed unexpectedly)] : Failed to connect to any server.
> Servers tried: [http-remoting://<myIpAddress>:8180
> (java.io.EOFException: XNIO000812: Connection closed unexpectedly)]
> Cause unknown. : Stack trace: javax.naming.CommunicationException:
> Failed to connect to any server. Servers tried:
> [http-remoting://<myIpAddress>:8180 (java.io.EOFException: XNIO000812:
> Connection closed unexpectedly)]
>
> at
>
org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244)
>
> at
>
org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)
>
> at
>
org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)
>
> at
>
org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)
>
> at
>
org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104)
>
> at
>
org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93)
>
> at
>
org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146)
>
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
>
> I am using port 8180 because port 8080 is already taken (jenkins).
>
> I have googled for this causes of this error. I found several hits that
> suggested various “solutions”. I tried them all. None of them worked.
> Here’s what I have tried:
>
> ·I ensured that no other process was using 8180. Some wildfly users have
> been in environments where a rogue process was writing to the undertow
> port. I used netstat in a loop to monitor any process using 8180. It
> just showed wildfly listening on it until my app made the connection
> attempt. Then it showed my app as well. No other apps.
>
> ·I tried using the port number offset feature. This used different port
> numbers but the problem remained.
>
> ·xml config, disable section security-realm-name=”ApplicationRealm”.
> This made no difference.
>
> ·In the interfaces section, interface name=”public” replace inet-address
> value=${jboss.bind.address:0.0.0.0} with value =
> “<myIpAddressAsADottedQuad>”. This did make a difference – I lost
> connectivity completely. This was fixed by me changing localhost in my
> remoting URL to the ip address as a dotted quad. Then I got the invalid
> message length error back.
>
> This seems like a very deep mystery to me. It might force me to abandon
> using wildfly on linux and say that it is only supported on windows. Any
> help will be much appreciated.
>
> Regards,
>
> Andrew Marlow.
>
>
http://www.andrewpetermarlow.co.uk
>
> _____________
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete
> the message and all copies; (ii) do not disclose, distribute or use the
> message in any manner; and (iii) notify the sender immediately. In
> addition, please be aware that any message addressed to our domain is
> subject to archiving and review by persons other than the intended
> recipient. Thank you.
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev