[JBoss JIRA] (JBJCA-1385) xa-datasource creates twice connections as much as max-pool-size
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1385?page=com.atlassian.jira.plugin... ]
Bartosz Spyrko-Śmietanko updated JBJCA-1385:
--------------------------------------------
Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/679
> xa-datasource creates twice connections as much as max-pool-size
> ----------------------------------------------------------------
>
> Key: JBJCA-1385
> URL: https://issues.jboss.org/browse/JBJCA-1385
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
>
> After createing connections by prefill, xa-datasource can have connection much more than max-pool-size.
> Although prefill try to create connections based on `SemaphoreConcurrentLinkedDequeManagedConnectionPool.poolsize`, the poolsize count is broken after closing connections by test failure.
> `SemaphoreConcurrentLinkedDequeManagedConnectionPool#removeConnectionListenerFromPool() is called 2 times per a connection during closing them, so that the poolsize can be decreased much more than existed connections.
> When the poolsize is 25, it become -25 after closing all connections. And prefill try to create 50 connections until the poolsize count becomes 25 from -25.
> `removeConnectionListenerFromPool()` is called as the following stacktrace during closing 1 connection.
> 1.
> {code}
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeConnectionListenerFromPool(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:-1)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:736)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:611)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:847)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:725)
> org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:472)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.broadcastConnectionError(XAManagedConnection.java:203)
> org.jboss.jca.adapters.jdbc.xa.XAManagedConnection$1.connectionErrorOccurred(XAManagedConnection.java:91)
> org.postgresql.ds.PGPooledConnection.fireConnectionFatalError(PGPooledConnection.java:183)
> org.postgresql.ds.PGPooledConnection.fireConnectionError(PGPooledConnection.java:237)
> org.postgresql.ds.PGPooledConnection.access$200(PGPooledConnection.java:38)
> org.postgresql.ds.PGPooledConnection$StatementHandler.invoke(PGPooledConnection.java:428)
> com.sun.proxy.$Proxy55.execute (Unknown Source)
> org.jboss.jca.adapters.jdbc.CheckValidConnectionSQL.isValidConnection(CheckValidConnectionSQL.java:74)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.isValidConnection(BaseWrapperManagedConnectionFactory.java:1304)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getInvalidConnections(BaseWrapperManagedConnectionFactory.java:1086)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:379)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> {code}
> 2.
> {code}
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeConnectionListenerFromPool(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:-1)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:452)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (JBJCA-1385) xa-datasource creates twice connections as much as max-pool-size
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1385?page=com.atlassian.jira.plugin... ]
Bartosz Spyrko-Śmietanko moved JBEAP-15549 to JBJCA-1385:
---------------------------------------------------------
Project: IronJacamar (was: JBoss Enterprise Application Platform)
Key: JBJCA-1385 (was: JBEAP-15549)
Workflow: classic default workflow (was: CDW with loose statuses v1)
Component/s: Core
(was: JCA)
Affects Version/s: WildFly/IronJacamar 1.4.2.Final
(was: 7.1.4.GA)
> xa-datasource creates twice connections as much as max-pool-size
> ----------------------------------------------------------------
>
> Key: JBJCA-1385
> URL: https://issues.jboss.org/browse/JBJCA-1385
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
>
> After createing connections by prefill, xa-datasource can have connection much more than max-pool-size.
> Although prefill try to create connections based on `SemaphoreConcurrentLinkedDequeManagedConnectionPool.poolsize`, the poolsize count is broken after closing connections by test failure.
> `SemaphoreConcurrentLinkedDequeManagedConnectionPool#removeConnectionListenerFromPool() is called 2 times per a connection during closing them, so that the poolsize can be decreased much more than existed connections.
> When the poolsize is 25, it become -25 after closing all connections. And prefill try to create 50 connections until the poolsize count becomes 25 from -25.
> `removeConnectionListenerFromPool()` is called as the following stacktrace during closing 1 connection.
> 1.
> {code}
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeConnectionListenerFromPool(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:-1)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:736)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:611)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:847)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:725)
> org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:472)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.broadcastConnectionError(XAManagedConnection.java:203)
> org.jboss.jca.adapters.jdbc.xa.XAManagedConnection$1.connectionErrorOccurred(XAManagedConnection.java:91)
> org.postgresql.ds.PGPooledConnection.fireConnectionFatalError(PGPooledConnection.java:183)
> org.postgresql.ds.PGPooledConnection.fireConnectionError(PGPooledConnection.java:237)
> org.postgresql.ds.PGPooledConnection.access$200(PGPooledConnection.java:38)
> org.postgresql.ds.PGPooledConnection$StatementHandler.invoke(PGPooledConnection.java:428)
> com.sun.proxy.$Proxy55.execute (Unknown Source)
> org.jboss.jca.adapters.jdbc.CheckValidConnectionSQL.isValidConnection(CheckValidConnectionSQL.java:74)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.isValidConnection(BaseWrapperManagedConnectionFactory.java:1304)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getInvalidConnections(BaseWrapperManagedConnectionFactory.java:1086)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:379)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> {code}
> 2.
> {code}
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeConnectionListenerFromPool(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:-1)
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:452)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet updated WFLY-11089:
-------------------------------------
Description:
When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
Size does matter, a small deployment is ok to upload.
was:
When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
> Size does matter, a small deployment is ok to upload.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3439?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3439:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-3439
> Reevaluate MultiphaseOverallContext.transformServerOperation
> ------------------------------------------------------------
>
> Key: WFCORE-3439
> URL: https://issues.jboss.org/browse/WFCORE-3439
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation.
> Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation.
> One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input.
> As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFCORE-323) Validate composite operation steps just before executing them
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-323?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-323:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3259
> Validate composite operation steps just before executing them
> -------------------------------------------------------------
>
> Key: WFCORE-323
> URL: https://issues.jboss.org/browse/WFCORE-323
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: EAP
>
> Say we have a composite operation with 2 steps:
> 1) /extension=org.jboss.as.messaging:add
> 2) /subsystem=messaging:add
> This will fail:
> Failed to execute batch: JBAS014739: No handler for add at address
> [("subsystem" => "messaging")]
> This fails because at the time of validation the /subsystem=messaging:add is not valid.
> To illustrate, the execution order is
> Validate 1-2
> 1
> 2
> A possible solution is to convert this to the following:
> V1
> 1
> V2 (works now because 1 has registered the subsystem API)
> 2
> I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2252:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-2252
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject the combination of a default value and required=true in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFCORE-1781) DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1781?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1781:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-1781
> DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1781
> URL: https://issues.jboss.org/browse/WFCORE-1781
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now.
> It also shouldn't be added if the DC is running admin-only.
> OTOH in all cases where it is not added, a different service should be added that will reject any slave registration requests that come in with the correct error codes that the slave knows how to parse. Currently that rejection is only happening for admin-only masters or slaves that are using cached-dc, which is not correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (DROOLS-3054) Highlight in expression builder previous selection in Scenario right panel
by Daniele Zonca (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3054?page=com.atlassian.jira.plugi... ]
Daniele Zonca commented on DROOLS-3054:
---------------------------------------
[~uxdlc]
One question for you.
Scenario:
- user map a column "Test" to field Person.name
- user does other activities and then he would like to edit column "Test" so left click again
- there is no place in expression builder component where he can see the existing mapping to Person.name
I think we can highlight in some way (blue background?) in the expression builder the old value.
What do you suggest?
> Highlight in expression builder previous selection in Scenario right panel
> --------------------------------------------------------------------------
>
> Key: DROOLS-3054
> URL: https://issues.jboss.org/browse/DROOLS-3054
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
>
> When the user edits the type of a column, the expression builder into the right panel should highlight the existing mapped type.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1649:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-1649
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months