[JBoss JIRA] (WFLY-3692) Update testsuite xslt scripts to be version independent
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3692:
----------------------------------
Summary: Update testsuite xslt scripts to be version independent
Key: WFLY-3692
URL: https://issues.jboss.org/browse/WFLY-3692
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Paul Ferraro
Assignee: Radoslav Husar
Fix For: 9.0.0.Beta1
We use a number of xslt scripts to transform server configuration for our tests. While some of these scripts are written in a subsystem version independent way, not all are. We should fix this so that new subsystem versions don't require changes to these files.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1864.
----------------------------
Resolution: Done
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
Simple solution: in {{UDP.createSockets()}}, check if {{bind_addr}} is valid using {{Util.checkIfValidAddress()}}.
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
OK, here's code which reproduces the error:
{noformat}
JChannel a=new JChannel("/home/bela/udp.xml").name("A");
TP tp=a.getProtocolStack().getTransport();
tp.setBindAddress(InetAddress.getByName("192.168.1.3"));
a.connect("boom");
{noformat}
But this is not how channels are usually created; the code above is only used to reproduce the issue.
Can you still show me how you trigger this in Infinispan ? The stack trace above shows that the error happens on {{JChannel.connect()}}; so how do you _create_ the channel in the first place ? Do you inject the bind address programmatically ?
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
How do you reproduce this ? {{TP.bind_addr}} has a {{@LocalAddress}} annotation, so when the channel is created and {{bind_addr}} is not a valid IP address available on a local NIC, an exception is thrown. This is done when the channel is created, way before it is connected.
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1864:
--------------------------------
The src for JGroups 3.4.4 doesn't match your stack trace. Can you tell me exactly which src code you used (or Git tag) ?
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.5, 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1159:
------------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1088470|https://bugzilla.redhat.com/show_bug.cgi?id=1088470] from ON_QA to VERIFIED
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBJCA-1161) NPE in SemaphoreArrayListManagedConnectionPool
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1161:
------------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1088470|https://bugzilla.redhat.com/show_bug.cgi?id=1088470] from ON_QA to VERIFIED
> NPE in SemaphoreArrayListManagedConnectionPool
> ----------------------------------------------
>
> Key: JBJCA-1161
> URL: https://issues.jboss.org/browse/JBJCA-1161
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 1.0.25.Final
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.26.Final
>
>
> {noformat}
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1159:
------------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1081058|https://bugzilla.redhat.com/show_bug.cgi?id=1081058] from ON_QA to VERIFIED
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBJCA-1161) NPE in SemaphoreArrayListManagedConnectionPool
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1161:
------------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1081058|https://bugzilla.redhat.com/show_bug.cgi?id=1081058] from ON_QA to VERIFIED
> NPE in SemaphoreArrayListManagedConnectionPool
> ----------------------------------------------
>
> Key: JBJCA-1161
> URL: https://issues.jboss.org/browse/JBJCA-1161
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 1.0.25.Final
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.26.Final
>
>
> {noformat}
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months