10:08 a.m.
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.
10:15 a.m.
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
10:17 a.m.
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
12:07 p.m.
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(a)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@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.
12:15 p.m.
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
--
- DML
12:33 p.m.
The connectors section of the config file is:
<subsystem xmlns="urn:jboss:domain:messaging:3.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<statistics-enabled>true</statistics-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm"
server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default"
name="http-acceptor"/>
<http-acceptor http-listener="default"
name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver"
value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm"
server-id="0"/>
</acceptors>
-----Original Message-----
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:wildfly-dev-bounces@lists.jboss.org] On
Behalf Of David M. Lloyd
Sent: 29 June 2016 18:15
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message
length of 1195725856
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}">
[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.
12:38 p.m.
That's for messaging not for remoting.
Andy
On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew <
Andrew.Marlow(a)fisglobal.com> wrote:
The connectors section of the config file is:
<subsystem xmlns="urn:jboss:domain:messaging:3.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<statistics-enabled>true</statistics-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm"
server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default"
name="http-acceptor"/>
<http-acceptor http-listener="default"
name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver"
value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm"
server-id="0"/>
</acceptors>
-----Original Message-----
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:
wildfly-dev-bounces(a)lists.jboss.org] On Behalf Of David M. Lloyd
Sent: 29 June 2016 18:15
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an
invalid message length of 1195725856
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}">
[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
--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
12:41 p.m.
Ah yes, so it is. How about this:
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<endpoint worker="default"/>
<connector name="remoting-connector"
socket-binding="remoting"/>
<http-connector name="http-remoting-connector"
connector-ref="default"/>
</subsystem>
From: Andrig Miller [mailto:anmiller@redhat.com]
Sent: 29 June 2016 18:38
To: Marlow, Andrew <Andrew.Marlow(a)fisglobal.com>
Cc: wildfly-dev <wildfly-dev(a)lists.jboss.org>
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message
length of 1195725856
That's for messaging not for remoting.
Andy
On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew
<Andrew.Marlow@fisglobal.com<mailto:Andrew.Marlow@fisglobal.com>> wrote:
The connectors section of the config file is:
<subsystem xmlns="urn:jboss:domain:messaging:3.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<statistics-enabled>true</statistics-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm"
server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default"
name="http-acceptor"/>
<http-acceptor http-listener="default"
name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver"
value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm"
server-id="0"/>
</acceptors>
-----Original Message-----
From:
wildfly-dev-bounces@lists.jboss.org<mailto:wildfly-dev-bounces@lists.jboss.org>
[mailto:wildfly-dev-bounces@lists.jboss.org<mailto:wildfly-dev-bounces@lists.jboss.org>]
On Behalf Of David M. Lloyd
Sent: 29 June 2016 18:15
To: wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message
length of 1195725856
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}">
[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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev<https://urldefens...
--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
_____________
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.
_____________
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.
1:06 p.m.
What did your configuration look like on Windows? You said it was working
on Windows. It seems strange that it would work on Windows and fail on
Linux.
Perhaps the entire configuration could be posted.
Andy
On Wed, Jun 29, 2016 at 11:41 AM, Marlow, Andrew <
Andrew.Marlow(a)fisglobal.com> wrote:
Ah yes, so it is. How about this:
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<endpoint worker="default"/>
<connector name="remoting-connector"
socket-binding="remoting"/>
<http-connector name="http-remoting-connector"
connector-ref="default"/>
</subsystem>
*From:* Andrig Miller [mailto:anmiller@redhat.com]
*Sent:* 29 June 2016 18:38
*To:* Marlow, Andrew <Andrew.Marlow(a)fisglobal.com>
*Cc:* wildfly-dev <wildfly-dev(a)lists.jboss.org>
*Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an
invalid message length of 1195725856
That's for messaging not for remoting.
Andy
On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew <
Andrew.Marlow(a)fisglobal.com> wrote:
The connectors section of the config file is:
<subsystem xmlns="urn:jboss:domain:messaging:3.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<statistics-enabled>true</statistics-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm"
server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default"
name="http-acceptor"/>
<http-acceptor http-listener="default"
name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver"
value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm"
server-id="0"/>
</acceptors>
-----Original Message-----
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:
wildfly-dev-bounces(a)lists.jboss.org] On Behalf Of David M. Lloyd
Sent: 29 June 2016 18:15
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an
invalid message length of 1195725856
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}">
[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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
_____________
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.
_____________
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
--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
1:12 p.m.
So in this case your "connector" is using the regular Remoting protocol
and it's using the "remoting" socket binding, which you have defined as
port 8180. Then you connect with http-remoting and it blows up.
If you want to connect with http-remoting then you need to make sure
that your http-connector is referencing the connector which is listening
on the port you're connecting to.
On 06/29/2016 12:41 PM, Marlow, Andrew wrote:
Ah yes, so it is. How about this:
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<endpoint worker="default"/>
<connector name="remoting-connector"
socket-binding="remoting"/>
<http-connector name="http-remoting-connector"
connector-ref="default"/>
</subsystem>
*From:*Andrig Miller [mailto:anmiller@redhat.com]
*Sent:* 29 June 2016 18:38
*To:* Marlow, Andrew <Andrew.Marlow(a)fisglobal.com>
*Cc:* wildfly-dev <wildfly-dev(a)lists.jboss.org>
*Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an
invalid message length of 1195725856
That's for messaging not for remoting.
Andy
On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew
<Andrew.Marlow(a)fisglobal.com <mailto:Andrew.Marlow@fisglobal.com>> wrote:
The connectors section of the config file is:
<subsystem xmlns="urn:jboss:domain:messaging:3.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<statistics-enabled>true</statistics-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor"/>
</http-connector>
<http-connector
name="http-connector-throughput" socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
<param key="batch-delay"
value="50"/>
</http-connector>
<in-vm-connector name="in-vm"
server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default"
name="http-acceptor"/>
<http-acceptor http-listener="default"
name="http-acceptor-throughput">
<param key="batch-delay"
value="50"/>
<param key="direct-deliver"
value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm"
server-id="0"/>
</acceptors>
-----Original Message-----
From: wildfly-dev-bounces(a)lists.jboss.org
<mailto:wildfly-dev-bounces@lists.jboss.org>
[mailto:wildfly-dev-bounces@lists.jboss.org
<mailto:wildfly-dev-bounces@lists.jboss.org>] On Behalf Of David M.
Lloyd
Sent: 29 June 2016 18:15
To: wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received
an invalid message length of 1195725856
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}">
[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 <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
_____________
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.
_____________
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
1:38 p.m.
Thankyou to David for identifying the problem. It is indeed a mystery why this works on
windows. Never mind, once I've got the config working on linux I will try the config
on windows. If Windows continues to work then that will be my new config file.
Now I just need to know how to change the config. Sorry I'm being a bit slow here but
I don't quite see how to say that I want http-remoting instead of remoting. When I
change "remoting" to "http-remoting" in the
socket-binding-group section wildfly complains that it doesn't like it. The error
is:-
19:23:43,096 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread)
WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "remoting"),
("connector" => "remoting-connector")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable
dependencies" => ["jboss.remoting.server.remoting-connector is missing
[jboss.binding.remoting]"]}
Maybe I need to add something to my global modules list. Here is what it is right now:
<global-modules>
<module name="org.apache.log4j" slot="main"/>
<module name="org.jboss.as.jmx" slot="main"/>
<module name="org.jboss.as.naming"
slot="main"/>
<module name="org.jboss.msc" slot="main"/>
<module name="org.jboss.remote-naming"
slot="main"/>
<module name="org.jboss.logging" slot="main"/>
<module name="org.jboss.xnio" slot="main"/>
<module name="org.jboss.xnio.nio" slot="main"/>
<module name="org.jboss.remoting3"
slot="main"/>
<module name="org.jboss.remoting3.remoting-jmx"
slot="main"/>
<module name="org.jboss.marshalling"
slot="main"/>
<module name="org.jboss.marshalling.river"
slot="main"/>
<module name="org.jboss.sasl" slot="main"/>
<module name="javax.jms.api" slot="main"/>
<module name="org.hornetq" slot="main"/>
</global-modules>
Please note: I am reluctant to post the entire config because the project is proprietary
and contains proprietary bits.
-----Original Message-----
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:wildfly-dev-bounces@lists.jboss.org] On
Behalf Of David M. Lloyd
Sent: 29 June 2016 19:13
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message
length of 1195725856
So in this case your "connector" is using the regular Remoting protocol and
it's using the "remoting" socket binding, which you have defined as port
8180. Then you connect with http-remoting and it blows up.
If you want to connect with http-remoting then you need to make sure that your
http-connector is referencing the connector which is listening on the port you're
connecting to.
On 06/29/2016 12:41 PM, Marlow, Andrew wrote:
Ah yes, so it is. How about this:
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<endpoint worker="default"/>
<connector name="remoting-connector"
socket-binding="remoting"/>
<http-connector name="http-remoting-connector"
connector-ref="default"/>
</subsystem>
*From:*Andrig Miller [mailto:anmiller@redhat.com]
*Sent:* 29 June 2016 18:38
*To:* Marlow, Andrew <Andrew.Marlow(a)fisglobal.com>
*Cc:* wildfly-dev <wildfly-dev(a)lists.jboss.org>
*Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received
an invalid message length of 1195725856
That's for messaging not for remoting.
Andy
On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew
<Andrew.Marlow(a)fisglobal.com <mailto:Andrew.Marlow@fisglobal.com>> wrote:
The connectors section of the config file is:
<subsystem xmlns="urn:jboss:domain:messaging:3.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<statistics-enabled>true</statistics-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput"
socket-binding="http">
<param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
<param key="batch-delay"
value="50"/>
</http-connector>
<in-vm-connector name="in-vm"
server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default"
name="http-acceptor"/>
<http-acceptor http-listener="default"
name="http-acceptor-throughput">
<param key="batch-delay"
value="50"/>
<param key="direct-deliver"
value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm"
server-id="0"/>
</acceptors>
[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.
1:52 p.m.
You already have an http-remoting connector set up. It's referencing
the web connector "default", which in turn (I can only guess based on
your bindings config, since you haven't shared your web server config)
is likely listening on port 8280. So if you connect to that port using
"http-remoting:", *or* connect to port 8180 using "remoting:",
you'll be
good to go. You just can't connect to 8180 using "http-remoting" or
8280 using "remoting", as attempting either of these will result in error.
On 06/29/2016 01:38 PM, Marlow, Andrew wrote:
Thankyou to David for identifying the problem. It is indeed a mystery
why this works on windows. Never mind, once I've got the config working on linux I
will try the config on windows. If Windows continues to work then that will be my new
config file.
Now I just need to know how to change the config. Sorry I'm being a bit slow here but
I don't quite see how to say that I want http-remoting instead of remoting. When I
change "remoting" to "http-remoting" in the
socket-binding-group section wildfly complains that it doesn't like it. The error
is:-
19:23:43,096 ERROR [org.jboss.as.controller.management-operation] (Controller Boot
Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "remoting"),
("connector" => "remoting-connector")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable
dependencies" => ["jboss.remoting.server.remoting-connector is missing
[jboss.binding.remoting]"]}
Maybe I need to add something to my global modules list. Here is what it is right now:
<global-modules>
<module name="org.apache.log4j" slot="main"/>
<module name="org.jboss.as.jmx" slot="main"/>
<module name="org.jboss.as.naming"
slot="main"/>
<module name="org.jboss.msc" slot="main"/>
<module name="org.jboss.remote-naming"
slot="main"/>
<module name="org.jboss.logging"
slot="main"/>
<module name="org.jboss.xnio" slot="main"/>
<module name="org.jboss.xnio.nio"
slot="main"/>
<module name="org.jboss.remoting3"
slot="main"/>
<module name="org.jboss.remoting3.remoting-jmx"
slot="main"/>
<module name="org.jboss.marshalling"
slot="main"/>
<module name="org.jboss.marshalling.river"
slot="main"/>
<module name="org.jboss.sasl" slot="main"/>
<module name="javax.jms.api" slot="main"/>
<module name="org.hornetq" slot="main"/>
</global-modules>
Please note: I am reluctant to post the entire config because the project is proprietary
and contains proprietary bits.
-----Original Message-----
From: wildfly-dev-bounces(a)lists.jboss.org [mailto:wildfly-dev-bounces@lists.jboss.org] On
Behalf Of David M. Lloyd
Sent: 29 June 2016 19:13
To: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message
length of 1195725856
So in this case your "connector" is using the regular Remoting protocol and
it's using the "remoting" socket binding, which you have defined as port
8180. Then you connect with http-remoting and it blows up.
If you want to connect with http-remoting then you need to make sure that your
http-connector is referencing the connector which is listening on the port you're
connecting to.
On 06/29/2016 12:41 PM, Marlow, Andrew wrote:
> Ah yes, so it is. How about this:
>
> <subsystem xmlns="urn:jboss:domain:remoting:3.0">
>
> <endpoint worker="default"/>
>
> <connector name="remoting-connector"
> socket-binding="remoting"/>
>
> <http-connector name="http-remoting-connector"
> connector-ref="default"/>
>
> </subsystem>
>
> *From:*Andrig Miller [mailto:anmiller@redhat.com]
> *Sent:* 29 June 2016 18:38
> *To:* Marlow, Andrew <Andrew.Marlow(a)fisglobal.com>
> *Cc:* wildfly-dev <wildfly-dev(a)lists.jboss.org>
> *Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received
> an invalid message length of 1195725856
>
> That's for messaging not for remoting.
>
> Andy
>
> On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew
> <Andrew.Marlow(a)fisglobal.com <mailto:Andrew.Marlow@fisglobal.com>>
wrote:
>
> The connectors section of the config file is:
>
> <subsystem xmlns="urn:jboss:domain:messaging:3.0">
> <hornetq-server>
> <security-enabled>false</security-enabled>
> <statistics-enabled>true</statistics-enabled>
> <journal-file-size>102400</journal-file-size>
>
> <connectors>
> <http-connector name="http-connector"
socket-binding="http">
> <param key="http-upgrade-endpoint"
value="http-acceptor"/>
> </http-connector>
> <http-connector
name="http-connector-throughput" socket-binding="http">
> <param key="http-upgrade-endpoint"
value="http-acceptor-throughput"/>
> <param key="batch-delay"
value="50"/>
> </http-connector>
> <in-vm-connector name="in-vm"
server-id="0"/>
> </connectors>
>
> <acceptors>
> <http-acceptor http-listener="default"
> name="http-acceptor"/>
> <http-acceptor http-listener="default"
> name="http-acceptor-throughput">
> <param key="batch-delay"
value="50"/>
> <param key="direct-deliver"
value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm"
server-id="0"/>
> </acceptors>
[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
--
- DML
3067
days inactive
3067
days old
11 comments
4 participants
participants (4)
-
Andrig Miller -
David M. Lloyd -
Marlow, Andrew -
Tomaž Cerar