[JBoss JIRA] (WFCORE-3183) Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3183?page=com.atlassian.jira.plugi... ]
Jan Kalina moved JBEAP-12727 to WFCORE-3183:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3183 (was: JBEAP-12727)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 3.0.0.Beta31
(was: 7.1.0.ER3)
> Unable to connect jboss-cli.sh using GS2-KRB5-PLUS
> --------------------------------------------------
>
> Key: WFCORE-3183
> URL: https://issues.jboss.org/browse/WFCORE-3183
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta31
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> I am unable to connect with jboss-cli.sh using GS2-KRB5-PLUS. This is not duplicity to JBEAP-12688. In this case even SASL client is not created.
> In server.log I see
> {code}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:37230 to /127.0.0.1:9993 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote}
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:37230 to localhost.localdomain/127.0.0.1:9993
> 17:25:10,564 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@2cb6a081
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes
> 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,576 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 56 bytes
> 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192]
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.CR5-redhat-1"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 17:25:10,580 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism GS2-KRB5-PLUS
> 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism PLAIN
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 88 bytes
> 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 17:25:10,638 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) CLI executor output:
> 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9993: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> {code}
> In jboss-cli.log I see.
> {code}
> 17:14:21,557 TRACE [org.wildfly.security] Created SaslClient [null] for mechanisms [GS2-KRB5-PLUS]
> 17:14:21,557 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> 17:14:21,558 DEBUG [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> 17:14:21,559 TRACE [org.jboss.remoting.endpoint] Registered exception result: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9223) fix comment formatting for "concurrent" cache in *ha.xml profiles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9223?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9223:
----------------------------------------
Please remove this commented out config. As soon as the server persists the file for any reason, it will disappear anyway, resulting in changes to the persistent format that are unrelated to the management op the user executed.
This is why you don't see a lot of educational comments in our standard config files.
> fix comment formatting for "concurrent" cache in *ha.xml profiles
> -----------------------------------------------------------------
>
> Key: WFLY-9223
> URL: https://issues.jboss.org/browse/WFLY-9223
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Labels: eap7.1-ok-for-CR1
>
> The current state (taken from standalone-ha.xml):
> {code:xml}
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> ...
> <!-- Alternate configuration to reduce lock contention for applications that make use of concurrent access to a web session -->
> <!-- Web sessions will be locked more frequently, but for shorter periods of time -->
> <!--
> ~ distributed-cache name="concurrent">
> ~ <file-store/>
> ~ </distributed-cache
> -->
> </cache-container>
> {code}
> After uncommenting, the resulting text is not a valid xml file.
> Please change it to:
> {code:xml}
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> ...
> <!-- Alternate configuration to reduce lock contention for applications that make use of concurrent access to a web session -->
> <!-- Web sessions will be locked more frequently, but for shorter periods of time -->
> <!--
> <distributed-cache name="concurrent">
> <file-store/>
> </distributed-cache>
> -->
> </cache-container>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9223) fix comment formatting for "concurrent" cache in *ha.xml profiles
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9223?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-12726 to WFLY-9223:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9223 (was: JBEAP-12726)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Beta1
(was: 7.1.0.ER3)
> fix comment formatting for "concurrent" cache in *ha.xml profiles
> -----------------------------------------------------------------
>
> Key: WFLY-9223
> URL: https://issues.jboss.org/browse/WFLY-9223
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Labels: eap7.1-ok-for-CR1
>
> The current state (taken from standalone-ha.xml):
> {code:xml}
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> ...
> <!-- Alternate configuration to reduce lock contention for applications that make use of concurrent access to a web session -->
> <!-- Web sessions will be locked more frequently, but for shorter periods of time -->
> <!--
> ~ distributed-cache name="concurrent">
> ~ <file-store/>
> ~ </distributed-cache
> -->
> </cache-container>
> {code}
> After uncommenting, the resulting text is not a valid xml file.
> Please change it to:
> {code:xml}
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> ...
> <!-- Alternate configuration to reduce lock contention for applications that make use of concurrent access to a web session -->
> <!-- Web sessions will be locked more frequently, but for shorter periods of time -->
> <!--
> <distributed-cache name="concurrent">
> <file-store/>
> </distributed-cache>
> -->
> </cache-container>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (HAWKULARQE-155) New Foreman Hostgroups for Fuse
by Hayk Hovsepyan (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-155?page=com.atlassian.jira.pl... ]
Hayk Hovsepyan reassigned HAWKULARQE-155:
-----------------------------------------
Assignee: Hayk Hovsepyan (was: Michael Foley)
> New Foreman Hostgroups for Fuse
> -------------------------------
>
> Key: HAWKULARQE-155
> URL: https://issues.jboss.org/browse/HAWKULARQE-155
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Hayk Hovsepyan
>
> We need several new foreman hostgroups for Fuse MiQ integration testing.
> 1. Run JBoss Fuse 6.3 on Karaf container. This is downstream Fuse project running on Karaf container. Install Hawkular Agent on JBoss Fuse.
> 2. Run Upstream Apache Karaf (downstream of JBoss Fuse) on Karaf container. Install Hawkular Agent on Upstream Apache Karaf.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1702) I am unable to create same repository name in another Organizational unit.
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1702?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-1702:
----------------------------------------
Give the repositories different names. Their names uniquely identify them.
Repositories are scoped at the workbench level, OU's allow for logical partitioning (and sharing) of repositories.
> I am unable to create same repository name in another Organizational unit.
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1702
> URL: https://issues.jboss.org/browse/DROOLS-1702
> Project: Drools
> Issue Type: Bug
> Reporter: Jai Nath Gupta
> Assignee: Michael Anstis
>
> Hi,
> I am unable to create same repository name in another Organizational unit.
> Example:
> OrganizationaUnit: HDFCBank
> Repository: Insurance
> Project:PolicyRule
> OrganizationaUnit: ICICIBank
> Repository: Insurance
> Project:PolicyRule
> I am unable to create Insurance Repository for ICICIBank.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1702) I am unable to create same repository name in another Organizational unit.
by Jai Nath Gupta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1702?page=com.atlassian.jira.plugi... ]
Jai Nath Gupta commented on DROOLS-1702:
----------------------------------------
But, When I update in*(may be another project add within this repository)*-
OrganizationaUnit: HDFCBank
*Repository: Insurance*
Project:PolicyRule
then changes will also happen in-
OrganizationaUnit: ICICIBank
*Repository: Insurance*
Project:PolicyRule
But this changes ICICIBank don't want.
What should we do ?
> I am unable to create same repository name in another Organizational unit.
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1702
> URL: https://issues.jboss.org/browse/DROOLS-1702
> Project: Drools
> Issue Type: Bug
> Reporter: Jai Nath Gupta
> Assignee: Michael Anstis
>
> Hi,
> I am unable to create same repository name in another Organizational unit.
> Example:
> OrganizationaUnit: HDFCBank
> Repository: Insurance
> Project:PolicyRule
> OrganizationaUnit: ICICIBank
> Repository: Insurance
> Project:PolicyRule
> I am unable to create Insurance Repository for ICICIBank.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-1116) TCPPING used with port_range can cause random OutOfMemoryError
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1116?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1116:
---------------------------
Description:
When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs.
The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for.
This intern will allow the connect to go through even though there is no accept thread waiting on it.
{code:java}
Connection getConnection(Address dest) throws Exception {
Connection conn=null;
Socket sock;
synchronized(conns) {
conn=(Connection)conns.get(dest);
if(conn == null) {
// changed by bela Jan 18 2004: use the bind address for the client sockets as well
SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
InetAddress tmpDest=((IpAddress)dest).getIpAddress();
SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
sock=new Socket();
sock.bind(tmpBindAddr);
sock.setKeepAlive(true);
sock.setTcpNoDelay(tcp_nodelay);
if(linger > 0)
sock.setSoLinger(true, linger);
else
sock.setSoLinger(false, -1);
sock.connect(destAddr, sock_conn_timeout);
{code}
This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
{code:java}
conn=new Connection(sock, dest);
conn.sendLocalAddress(local_addr);
notifyConnectionOpened(dest);
// conns.put(dest, conn);
addConnection(dest, conn);
conn.init();
if(log.isInfoEnabled()) log.info("created socket to " + dest);
}
return conn;
}
{code}
When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
{code:java}
len=in.readInt();
if(len > buf.length)
buf=new byte[len];
in.readFully(buf, 0, len);
updateLastAccessed();
receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
{code}
This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
A test program that reproduces the port collision is attached. Sample invocation below.
bash-2.05$ java Test vlinux101
Connected : 6789 to 6789 on try 46267
bash-2.05$
was:
When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
{code:java}
Connection getConnection(Address dest) throws Exception {
Connection conn=null;
Socket sock;
synchronized(conns) {
conn=(Connection)conns.get(dest);
if(conn == null) {
// changed by bela Jan 18 2004: use the bind address for the client sockets as well
SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
InetAddress tmpDest=((IpAddress)dest).getIpAddress();
SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
sock=new Socket();
sock.bind(tmpBindAddr);
sock.setKeepAlive(true);
sock.setTcpNoDelay(tcp_nodelay);
if(linger > 0)
sock.setSoLinger(true, linger);
else
sock.setSoLinger(false, -1);
sock.connect(destAddr, sock_conn_timeout);
{code}
This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
{code:java}
conn=new Connection(sock, dest);
conn.sendLocalAddress(local_addr);
notifyConnectionOpened(dest);
// conns.put(dest, conn);
addConnection(dest, conn);
conn.init();
if(log.isInfoEnabled()) log.info("created socket to " + dest);
}
return conn;
}
{code}
When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
{code:java}
len=in.readInt();
if(len > buf.length)
buf=new byte[len];
in.readFully(buf, 0, len);
updateLastAccessed();
receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
{code}
This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
A test program that reproduces the port collision is attached. Sample invocation below.
bash-2.05$ java Test vlinux101
Connected : 6789 to 6789 on try 46267
bash-2.05$
> TCPPING used with port_range can cause random OutOfMemoryError
> --------------------------------------------------------------
>
> Key: JGRP-1116
> URL: https://issues.jboss.org/browse/JGRP-1116
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.4.1 SP4
> Environment: java 1.5, linux 2.6.9-78.0.8.EL 32/64 bit, jboss 4.2.2
> Reporter: Sanjay Prasad
> Assignee: Bela Ban
> Fix For: 2.4.8
>
> Attachments: Test.java
>
>
> When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs.
> The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for.
> This intern will allow the connect to go through even though there is no accept thread waiting on it.
> {code:java}
> Connection getConnection(Address dest) throws Exception {
> Connection conn=null;
> Socket sock;
> synchronized(conns) {
> conn=(Connection)conns.get(dest);
> if(conn == null) {
> // changed by bela Jan 18 2004: use the bind address for the client sockets as well
> SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
> InetAddress tmpDest=((IpAddress)dest).getIpAddress();
> SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
> sock=new Socket();
> sock.bind(tmpBindAddr);
> sock.setKeepAlive(true);
> sock.setTcpNoDelay(tcp_nodelay);
> if(linger > 0)
> sock.setSoLinger(true, linger);
> else
> sock.setSoLinger(false, -1);
> sock.connect(destAddr, sock_conn_timeout);
> {code}
> This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
> {code:java}
> conn=new Connection(sock, dest);
> conn.sendLocalAddress(local_addr);
> notifyConnectionOpened(dest);
> // conns.put(dest, conn);
> addConnection(dest, conn);
> conn.init();
> if(log.isInfoEnabled()) log.info("created socket to " + dest);
> }
> return conn;
> }
> {code}
> When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
> {code:java}
> len=in.readInt();
> if(len > buf.length)
> buf=new byte[len];
> in.readFully(buf, 0, len);
> updateLastAccessed();
> receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
> {code}
>
> This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
> A test program that reproduces the port collision is attached. Sample invocation below.
> bash-2.05$ java Test vlinux101
> Connected : 6789 to 6789 on try 46267
> bash-2.05$
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-1116) TCPPING used with port_range can cause random OutOfMemoryError
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1116?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1116:
---------------------------
Description:
When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
{code:java}
Connection getConnection(Address dest) throws Exception {
Connection conn=null;
Socket sock;
synchronized(conns) {
conn=(Connection)conns.get(dest);
if(conn == null) {
// changed by bela Jan 18 2004: use the bind address for the client sockets as well
SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
InetAddress tmpDest=((IpAddress)dest).getIpAddress();
SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
sock=new Socket();
sock.bind(tmpBindAddr);
sock.setKeepAlive(true);
sock.setTcpNoDelay(tcp_nodelay);
if(linger > 0)
sock.setSoLinger(true, linger);
else
sock.setSoLinger(false, -1);
sock.connect(destAddr, sock_conn_timeout);
{code}
This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
{code:java}
conn=new Connection(sock, dest);
conn.sendLocalAddress(local_addr);
notifyConnectionOpened(dest);
// conns.put(dest, conn);
addConnection(dest, conn);
conn.init();
if(log.isInfoEnabled()) log.info("created socket to " + dest);
}
return conn;
}
{code}
When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
{code:java}
len=in.readInt();
if(len > buf.length)
buf=new byte[len];
in.readFully(buf, 0, len);
updateLastAccessed();
receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
{code}
This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
A test program that reproduces the port collision is attached. Sample invocation below.
bash-2.05$ java Test vlinux101
Connected : 6789 to 6789 on try 46267
bash-2.05$
was:
When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
{code:java}
Connection getConnection(Address dest) throws Exception {
Connection conn=null;
Socket sock;
synchronized(conns) {
conn=(Connection)conns.get(dest);
if(conn == null) {
// changed by bela Jan 18 2004: use the bind address for the client sockets as well
SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
InetAddress tmpDest=((IpAddress)dest).getIpAddress();
SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
sock=new Socket();
sock.bind(tmpBindAddr);
sock.setKeepAlive(true);
sock.setTcpNoDelay(tcp_nodelay);
if(linger > 0)
sock.setSoLinger(true, linger);
else
sock.setSoLinger(false, -1);
sock.connect(destAddr, sock_conn_timeout);
{code}
This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
{coe:java}
conn=new Connection(sock, dest);
conn.sendLocalAddress(local_addr);
notifyConnectionOpened(dest);
// conns.put(dest, conn);
addConnection(dest, conn);
conn.init();
if(log.isInfoEnabled()) log.info("created socket to " + dest);
}
return conn;
}
{code}
When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
{code:java}
len=in.readInt();
if(len > buf.length)
buf=new byte[len];
in.readFully(buf, 0, len);
updateLastAccessed();
receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
{code}
This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
A test program that reproduces the port collision is attached. Sample invocation below.
bash-2.05$ java Test vlinux101
Connected : 6789 to 6789 on try 46267
bash-2.05$
> TCPPING used with port_range can cause random OutOfMemoryError
> --------------------------------------------------------------
>
> Key: JGRP-1116
> URL: https://issues.jboss.org/browse/JGRP-1116
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.4.1 SP4
> Environment: java 1.5, linux 2.6.9-78.0.8.EL 32/64 bit, jboss 4.2.2
> Reporter: Sanjay Prasad
> Assignee: Bela Ban
> Fix For: 2.4.8
>
> Attachments: Test.java
>
>
> When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
> {code:java}
> Connection getConnection(Address dest) throws Exception {
> Connection conn=null;
> Socket sock;
> synchronized(conns) {
> conn=(Connection)conns.get(dest);
> if(conn == null) {
> // changed by bela Jan 18 2004: use the bind address for the client sockets as well
> SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
> InetAddress tmpDest=((IpAddress)dest).getIpAddress();
> SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
> sock=new Socket();
> sock.bind(tmpBindAddr);
> sock.setKeepAlive(true);
> sock.setTcpNoDelay(tcp_nodelay);
> if(linger > 0)
> sock.setSoLinger(true, linger);
> else
> sock.setSoLinger(false, -1);
> sock.connect(destAddr, sock_conn_timeout);
> {code}
> This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
> {code:java}
> conn=new Connection(sock, dest);
> conn.sendLocalAddress(local_addr);
> notifyConnectionOpened(dest);
> // conns.put(dest, conn);
> addConnection(dest, conn);
> conn.init();
> if(log.isInfoEnabled()) log.info("created socket to " + dest);
> }
> return conn;
> }
> {code}
> When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
> {code:java}
> len=in.readInt();
> if(len > buf.length)
> buf=new byte[len];
> in.readFully(buf, 0, len);
> updateLastAccessed();
> receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
> {code}
>
> This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
> A test program that reproduces the port collision is attached. Sample invocation below.
> bash-2.05$ java Test vlinux101
> Connected : 6789 to 6789 on try 46267
> bash-2.05$
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-1116) TCPPING used with port_range can cause random OutOfMemoryError
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1116?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1116:
---------------------------
Description:
When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
{code:java}
Connection getConnection(Address dest) throws Exception {
Connection conn=null;
Socket sock;
synchronized(conns) {
conn=(Connection)conns.get(dest);
if(conn == null) {
// changed by bela Jan 18 2004: use the bind address for the client sockets as well
SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
InetAddress tmpDest=((IpAddress)dest).getIpAddress();
SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
sock=new Socket();
sock.bind(tmpBindAddr);
sock.setKeepAlive(true);
sock.setTcpNoDelay(tcp_nodelay);
if(linger > 0)
sock.setSoLinger(true, linger);
else
sock.setSoLinger(false, -1);
sock.connect(destAddr, sock_conn_timeout);
{code}
This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
{coe:java}
conn=new Connection(sock, dest);
conn.sendLocalAddress(local_addr);
notifyConnectionOpened(dest);
// conns.put(dest, conn);
addConnection(dest, conn);
conn.init();
if(log.isInfoEnabled()) log.info("created socket to " + dest);
}
return conn;
}
{code}
When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
{code:java}
len=in.readInt();
if(len > buf.length)
buf=new byte[len];
in.readFully(buf, 0, len);
updateLastAccessed();
receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
{code}
This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
A test program that reproduces the port collision is attached. Sample invocation below.
bash-2.05$ java Test vlinux101
Connected : 6789 to 6789 on try 46267
bash-2.05$
was:
When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
Connection getConnection(Address dest) throws Exception {
Connection conn=null;
Socket sock;
synchronized(conns) {
conn=(Connection)conns.get(dest);
if(conn == null) {
// changed by bela Jan 18 2004: use the bind address for the client sockets as well
SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
InetAddress tmpDest=((IpAddress)dest).getIpAddress();
SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
sock=new Socket();
sock.bind(tmpBindAddr);
sock.setKeepAlive(true);
sock.setTcpNoDelay(tcp_nodelay);
if(linger > 0)
sock.setSoLinger(true, linger);
else
sock.setSoLinger(false, -1);
sock.connect(destAddr, sock_conn_timeout);
This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
conn=new Connection(sock, dest);
conn.sendLocalAddress(local_addr);
notifyConnectionOpened(dest);
// conns.put(dest, conn);
addConnection(dest, conn);
conn.init();
if(log.isInfoEnabled()) log.info("created socket to " + dest);
}
return conn;
}
When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
len=in.readInt();
if(len > buf.length)
buf=new byte[len];
in.readFully(buf, 0, len);
updateLastAccessed();
receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
A test program that reproduces the port collision is attached. Sample invocation below.
bash-2.05$ java Test vlinux101
Connected : 6789 to 6789 on try 46267
bash-2.05$
> TCPPING used with port_range can cause random OutOfMemoryError
> --------------------------------------------------------------
>
> Key: JGRP-1116
> URL: https://issues.jboss.org/browse/JGRP-1116
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.4.1 SP4
> Environment: java 1.5, linux 2.6.9-78.0.8.EL 32/64 bit, jboss 4.2.2
> Reporter: Sanjay Prasad
> Assignee: Bela Ban
> Fix For: 2.4.8
>
> Attachments: Test.java
>
>
> When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
> {code:java}
> Connection getConnection(Address dest) throws Exception {
> Connection conn=null;
> Socket sock;
> synchronized(conns) {
> conn=(Connection)conns.get(dest);
> if(conn == null) {
> // changed by bela Jan 18 2004: use the bind address for the client sockets as well
> SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
> InetAddress tmpDest=((IpAddress)dest).getIpAddress();
> SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
> sock=new Socket();
> sock.bind(tmpBindAddr);
> sock.setKeepAlive(true);
> sock.setTcpNoDelay(tcp_nodelay);
> if(linger > 0)
> sock.setSoLinger(true, linger);
> else
> sock.setSoLinger(false, -1);
> sock.connect(destAddr, sock_conn_timeout);
> {code}
> This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
> {coe:java}
> conn=new Connection(sock, dest);
> conn.sendLocalAddress(local_addr);
> notifyConnectionOpened(dest);
> // conns.put(dest, conn);
> addConnection(dest, conn);
> conn.init();
> if(log.isInfoEnabled()) log.info("created socket to " + dest);
> }
> return conn;
> }
> {code}
> When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
> {code:java}
> len=in.readInt();
> if(len > buf.length)
> buf=new byte[len];
>
> in.readFully(buf, 0, len);
> updateLastAccessed();
> receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
> {code}
>
> This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
> A test program that reproduces the port collision is attached. Sample invocation below.
> bash-2.05$ java Test vlinux101
> Connected : 6789 to 6789 on try 46267
> bash-2.05$
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9222) Query MBean names takes forever when having many loggers and many classes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9222?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9222:
----------------------------------------
[~jamezp] Is this resolved now? I know I plan further improvements in the JMX stuff for WildFly Core 4 / WildFly 12 (see WFCORE-2719), but I don't remember clearly if you did something specific to logging to help with this.
> Query MBean names takes forever when having many loggers and many classes
> -------------------------------------------------------------------------
>
> Key: WFLY-9222
> URL: https://issues.jboss.org/browse/WFLY-9222
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Logging
> Affects Versions: 10.1.0.Final
> Environment: Windows 7 and Windows 10
> Reporter: Steffen Czymmeck
> Attachments: manyClasses.ear, standalone.xml
>
>
> If you configure many loggers (~300) and deploy a rather big ear with many classes, it takes forever to query mbean names with
> javax.management.MBeanServer#queryNames or via. jconsoles MBeans tab.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months