[JBoss JIRA] (AG-34) Reset connection attributes on close
by Luis Barreiro (JIRA)
Luis Barreiro created AG-34:
-------------------------------
Summary: Reset connection attributes on close
Key: AG-34
URL: https://issues.jboss.org/browse/AG-34
Project: Agroal
Issue Type: Bug
Components: pool
Affects Versions: 0,2
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 0.3
Connections that are acquired from the pool should have their attributes according to the configuration.
This is particularly important for attributes relating to transactions (and these are the ones addressable now, as there are default values for them supplied in the configuration)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9353) system property to set cluster name
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-9353?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-9353:
------------------------------------
[~pferraro] I think that covers the ejb one, from a holistic level if someone needs to separate clusters they can use different multicast address or change the cluster names on the transport level. So if one needs to change the transport cluster names, I think they would need to change them all (else say changing the ejb one separates the SLSB, but then sfsb and web would still cluster). While there could be an unusual setup, it seems like the typical use case if one was going to change the cluster name would need to change it on all transports.
> system property to set cluster name
> -----------------------------------
>
> Key: WFLY-9353
> URL: https://issues.jboss.org/browse/WFLY-9353
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Brad Maxwell
> Assignee: Paul Ferraro
>
> The cluster name is basically always server/web/ejb/hibernate/... as shown below. It would be useful to define a system property substitution in the standard configs to make it easy to set for instances where multiple clusters are needed.
> Something like ${jboss.cluster.name:}-ejb or ${jboss.partition.name:DefaultPartition} would make it clear what the cluster name is and how to change it.
> {code}
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> <transport lock-timeout="60000" cluster="${jboss.cluster.name:}-ejb"/>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> <transport lock-timeout="60000"/>
> ...
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> <transport lock-timeout="60000"/>
> ...
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> <transport lock-timeout="60000"/>
> ...
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> <transport lock-timeout="60000"/>
> ...
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (AG-33) Calling close does not seem to close a connection
by Paulo Lopes (JIRA)
Paulo Lopes created AG-33:
-----------------------------
Summary: Calling close does not seem to close a connection
Key: AG-33
URL: https://issues.jboss.org/browse/AG-33
Project: Agroal
Issue Type: Bug
Components: pool
Affects Versions: 0.2
Reporter: Paulo Lopes
Assignee: Luis Barreiro
In vert.x we have the test:
{code}
@Test
public void testStreamOnClosedConnection() {
String sql = "SELECT ID, FNAME, LNAME FROM select_table ORDER BY ID";
final AtomicInteger cnt = new AtomicInteger(0);
final SQLConnection conn = connection();
conn.queryStream(sql, onSuccess(res -> {
conn.close();
res.resultSetClosedHandler(v -> {
fail("Should not happen");
}).handler(row -> {
fail("Should not happen");
}).endHandler(v -> {
fail("Should not happen");
}).exceptionHandler(t -> {
testComplete();
});
}));
await();
}
{code}
Now once the query is run we call conn.close() and all remaining handlers show fail except the exception handler, however the test fails and I do get the data from the result set.
This is quite strange since it works for other pools C3P0, Hikari, BoneCP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9353) system property to set cluster name
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9353?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-9353:
------------------------------------
[~bmaxwell] The cluster name can be manipulated via the Infinispan transport.
e.g.
{code:xml}
<cache-container name="ejb">
<transport cluster="${jboss.cluster.name}-ejb"/>
</cache-container>
{code}
Is this insufficient?
> system property to set cluster name
> -----------------------------------
>
> Key: WFLY-9353
> URL: https://issues.jboss.org/browse/WFLY-9353
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Brad Maxwell
> Assignee: Paul Ferraro
>
> The cluster name is basically always server/web/ejb/hibernate/... as shown below. It would be useful to define a system property substitution in the standard configs to make it easy to set for instances where multiple clusters are needed.
> Something like ${jboss.cluster.name:}-ejb or ${jboss.partition.name:DefaultPartition} would make it clear what the cluster name is and how to change it.
> {code}
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> <transport lock-timeout="60000" cluster="${jboss.cluster.name:}-ejb"/>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> <transport lock-timeout="60000"/>
> ...
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> <transport lock-timeout="60000"/>
> ...
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> <transport lock-timeout="60000"/>
> ...
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> <transport lock-timeout="60000"/>
> ...
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3302?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3302:
------------------------------------------
I've submitted master/3.x/3.0.x PRs to workaround this (WFCORE-3302) by closing the endpoint. What's interesting, is that simply doing this didn't solve the problem:
endpoint.close();
This, however, did:
endpoint.closeAsync();
endpoint.awaitClosed(); // with some try/catch boilerplate around it to handle InterruptedException
>From a naive point of view it seems like those two should be semantically equivalent. I've reported this on REM3-303 which is the main JIRA tracking this problem.
> Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-3302
> URL: https://issues.jboss.org/browse/WFCORE-3302
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets.
> Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet:
> {code}
> java.lang.RuntimeException: java.net.BindException: Address already in use: bind
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92)
> at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88)
> at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94)
> at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346)
> {code}
> These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests.
> I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method.
> The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens:
> {code}
> "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307)
> - locked <0xc0d> (a java.lang.Object)
> at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229)
> at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149)
> - locked <0xc38> (a java.util.HashSet)
> at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl)
> - locked <0xc39> (a java.util.Collections$UnmodifiableSet)
> - locked <0xc3a> (a sun.nio.ch.Util$2)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:519)
> {code}
> That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket.
> I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed.
> I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1737) Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1737?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1737:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
> ---------------------------------------------------------------
>
> Key: DROOLS-1737
> URL: https://issues.jboss.org/browse/DROOLS-1737
> Project: Drools
> Issue Type: Bug
> Reporter: Nikolay Plekhanov
> Assignee: Mario Fusco
> Attachments: drools720issue.zip
>
>
> We are trying to migrate project on newest version of drools, but had regression testing failure. We have extracted simplest scenario to reproduce it.
> {code}
> package demo
> import demo.DataRow;
> import demo.ExpectedError;
> import demo.Dark;
> rule "rule-1"
> salience 130
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID, $d: row[Dark.Xantor.wand] != null)
> $b: DataRow(viewId == Dark.Aragorn.$ID, row[Dark.Aragorn.sword] == $d)
> $c: DataRow(viewId == Dark.Tant.$ID, row[Dark.Tant.crown] == $d)
> then
> $a.setField(Dark.Xantor.sword, $c.getField(Dark.Tant.sword));
> $a.setField(Dark.Xantor.chainmail, $c.getField(Dark.Tant.tower));
> update($a);
> end
> rule "rule-2"
> salience 110
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID,
> $b: row[Dark.Xantor.wand] != null,
> row[Dark.Xantor.sword] == "claymore",
> row[Dark.Xantor.bow] == null)
> then
> throw new ExpectedError();
> end
> {code}
> initial facts:
> {code}
> Dark.Tant( crown: 123, sword: claymore )
> Dark.Aragorn( sword: 123 )
> Dark.Xantor( wand: 123 )
> {code}
> Expected to catch ExpectedError (rule-2 to be fired), but nothing happens.
> Detailed exploit attached as Maven project with two executable modules. Main650 class demonstrates positive scenario (it run rules with 6.5.0.Final), Main720 (runs the same rules with 7.2.0.Final) - negative. "Main" class contains basic scenario without link to drools version
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ELY-455) OAuth2 Credential Store
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-455:
--------------------------------------
Whilst we may want to use these kinds of tokens independently of KeyCloak, if there is an interoperability opportunity with another tool I think we should definitely take it into account.
> OAuth2 Credential Store
> -----------------------
>
> Key: ELY-455
> URL: https://issues.jboss.org/browse/ELY-455
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Credential Store
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Fix For: 1.2.0.Beta5
>
>
> Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ELY-455) OAuth2 Credential Store
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor commented on ELY-455:
--------------------------------
In essence it is the same idea. Not sure if he finished the implementation though.
This issue would allow clients backed by Elytron to automatically manage tokens based on OIDC and OAuth2. Right now, Elytron only obtains access token without manage token's life cycle.
> OAuth2 Credential Store
> -----------------------
>
> Key: ELY-455
> URL: https://issues.jboss.org/browse/ELY-455
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Credential Store
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Fix For: 1.2.0.Beta5
>
>
> Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1737) Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
by Nikolay Plekhanov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1737?page=com.atlassian.jira.plugi... ]
Nikolay Plekhanov updated DROOLS-1737:
--------------------------------------
Attachment: drools720issue.zip
> Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
> ---------------------------------------------------------------
>
> Key: DROOLS-1737
> URL: https://issues.jboss.org/browse/DROOLS-1737
> Project: Drools
> Issue Type: Bug
> Reporter: Nikolay Plekhanov
> Assignee: Edson Tirelli
> Attachments: drools720issue.zip
>
>
> We are trying to migrate project on newest version of drools, but had regression testing failure. We have extracted simplest scenario to reproduce it.
> {code}
> package demo
> import demo.DataRow;
> import demo.ExpectedError;
> import demo.Dark;
> rule "rule-1"
> salience 130
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID, $d: row[Dark.Xantor.wand] != null)
> $b: DataRow(viewId == Dark.Aragorn.$ID, row[Dark.Aragorn.sword] == $d)
> $c: DataRow(viewId == Dark.Tant.$ID, row[Dark.Tant.crown] == $d)
> then
> $a.setField(Dark.Xantor.sword, $c.getField(Dark.Tant.sword));
> $a.setField(Dark.Xantor.chainmail, $c.getField(Dark.Tant.tower));
> update($a);
> end
> rule "rule-2"
> salience 110
> no-loop true
> when
> $a: DataRow(viewId == Dark.Xantor.$ID,
> $b: row[Dark.Xantor.wand] != null,
> row[Dark.Xantor.sword] == "claymore",
> row[Dark.Xantor.bow] == null)
> then
> throw new ExpectedError();
> end
> {code}
> initial facts:
> {code}
> Dark.Tant( crown: 123, sword: claymore )
> Dark.Aragorn( sword: 123 )
> Dark.Xantor( wand: 123 )
> {code}
> Expected to catch ExpectedError (rule-2 to be fired), but nothing happens.
> Detailed exploit attached as Maven project with two executable modules. Main650 class demonstrates positive scenario (it run rules with 6.5.0.Final), Main720 (runs the same rules with 7.2.0.Final) - negative. "Main" class contains basic scenario without link to drools version
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1737) Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
by Nikolay Plekhanov (JIRA)
Nikolay Plekhanov created DROOLS-1737:
-----------------------------------------
Summary: Rule is ignored after migration from 6.5.0.Final to 7.2.0.Final
Key: DROOLS-1737
URL: https://issues.jboss.org/browse/DROOLS-1737
Project: Drools
Issue Type: Bug
Reporter: Nikolay Plekhanov
Assignee: Edson Tirelli
Attachments: drools720issue.zip
We are trying to migrate project on newest version of drools, but had regression testing failure. We have extracted simplest scenario to reproduce it.
{code}
package demo
import demo.DataRow;
import demo.ExpectedError;
import demo.Dark;
rule "rule-1"
salience 130
no-loop true
when
$a: DataRow(viewId == Dark.Xantor.$ID, $d: row[Dark.Xantor.wand] != null)
$b: DataRow(viewId == Dark.Aragorn.$ID, row[Dark.Aragorn.sword] == $d)
$c: DataRow(viewId == Dark.Tant.$ID, row[Dark.Tant.crown] == $d)
then
$a.setField(Dark.Xantor.sword, $c.getField(Dark.Tant.sword));
$a.setField(Dark.Xantor.chainmail, $c.getField(Dark.Tant.tower));
update($a);
end
rule "rule-2"
salience 110
no-loop true
when
$a: DataRow(viewId == Dark.Xantor.$ID,
$b: row[Dark.Xantor.wand] != null,
row[Dark.Xantor.sword] == "claymore",
row[Dark.Xantor.bow] == null)
then
throw new ExpectedError();
end
{code}
initial facts:
{code}
Dark.Tant( crown: 123, sword: claymore )
Dark.Aragorn( sword: 123 )
Dark.Xantor( wand: 123 )
{code}
Expected to catch ExpectedError (rule-2 to be fired), but nothing happens.
Detailed exploit attached as Maven project with two executable modules. Main650 class demonstrates positive scenario (it run rules with 6.5.0.Final), Main720 (runs the same rules with 7.2.0.Final) - negative. "Main" class contains basic scenario without link to drools version
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months