This is just the socket bindings; it's the connectors that determine
what the protocol is.
On 06/29/2016 12:07 PM, Marlow, Andrew wrote:
Apologies for top-posting, I am forced to use LookOut!
I never knew about HTTP Upgrade. I knew that wildfly multiplexed all the
old jboss ports onto one http port but didn’t know this was how it was done.
The client is most definately using http-remoting. I thought wildfly was
as well, here is the end of the config file:
<socket-binding-group name="standard-sockets"
default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http"
interface="management"
port="${jboss.management.http.port:9991}"/>
<socket-binding name="management-https"
interface="management"
port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp"
port="${jboss.ajp.port:8009}"/>
<socket-binding name="http"
port="${jboss.http.port:8280}"/>
<socket-binding name="remoting"
port="${jboss.http.port:8180}"/>
<socket-binding name="https"
port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment"
port="4712"/>
<socket-binding name="txn-status-manager"
port="4713"/>
<socket-binding name="messaging" interface="messaging"
port="5445"/>
<socket-binding name="messaging-throughput"
interface="messaging" port="5455"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
Maybe this is where I am going wrong somehow....
*From:*wildfly-dev-bounces@lists.jboss.org
[mailto:wildfly-dev-bounces@lists.jboss.org] *On Behalf Of *Tomaž Cerar
*Sent:* 29 June 2016 16:18
On Wed, Jun 29, 2016 at 5:15 PM, David M. Lloyd <david.lloyd(a)redhat.com
<mailto:david.lloyd@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.
[snip]
_____________
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