[JBoss JIRA] (LOGMGR-264) Allow logger nodes to be used on different log contexts
by James Perkins (Jira)
James Perkins created LOGMGR-264:
------------------------------------
Summary: Allow logger nodes to be used on different log contexts
Key: LOGMGR-264
URL: https://issues.jboss.org/browse/LOGMGR-264
Project: JBoss Log Manager
Issue Type: Enhancement
Components: core
Reporter: James Perkins
Assignee: James Perkins
Currently logger nodes belong to a single log context. This means that shared classes with static loggers are created on the log context that initializes the class. It would be useful if static loggers on shared classes could log to different log contexts.
The concept would be something of a switchable log context for a logger. This would be based on the TCCL and the class loader needs to be registered in order to enable this functionality.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBJCA-1398) Connection leak when there is an exception during getConnection for NoTransaction resource adapter
by Stephen Fikes (Jira)
Stephen Fikes created JBJCA-1398:
------------------------------------
Summary: Connection leak when there is an exception during getConnection for NoTransaction resource adapter
Key: JBJCA-1398
URL: https://issues.jboss.org/browse/JBJCA-1398
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: 1.0.31.Final, 1.0.38.Final, 1.4.10
Reporter: Stephen Fikes
When an exception occurs with a {{NoTransaction}} resource adapter during a {{getConnection}} attempt the pool leaks the connection. The exception (simulating a timeout of the underlying connect attempt) detail is below.
{code}
... WARNING [support.jboss.ejb.session.SessionBean] (ServerService Thread Pool -- 51) Failed to get a connection: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]: javax.resource.ResourceException: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:521)
at support.redhat.jboss.jca.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:61)
...
Caused by: javax.resource.ResourceException: Simulate timeout
at support.redhat.jboss.jca.ManagedConnectionImpl.getConnection(ManagedConnectionImpl.java:61)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:508)
...
{code}
There seems to be a difference in a {{NoTransaction}} and an {{XATransaction}} adapter where {{returnConnection}} is triggered by the {{TxConnectionManagerImpl}}.
{code}
... [BMAN] org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.returnConnection(SemaphoreArrayListManagedConnectionPool.java:-1)
... org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:633)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:456)
... org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionDisconnected(TxConnectionManagerImpl.java:515)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
{code}
For {{NoTransaction}} adapter, however, the abstract implementation is used:
{code}
... [BMAN] org.jboss.jca.core.connectionmanager.AbstractConnectionManager.managedConnectionDisconnected(AbstractConnectionManager.java:697)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
{code}
The empty implementation for [AbstractConnectionManager.managedConnectionDisconnected|https://github.co...] does nothing so the connection is not returned as it would be for a transactional implementation.
I also see the same issue with IronJacamar 1.4.18.Final so this issue remains in the latest release.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JBJCA-1398) Connection leak when there is an exception during getConnection for NoTransaction resource adapter
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1398?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1398:
---------------------------------
Description:
When an exception occurs with a {{NoTransaction}} resource adapter during a {{getConnection}} attempt the pool leaks the connection. The exception (simulating a timeout of the underlying connect attempt) detail is below.
{code}
... WARNING [support.jboss.ejb.session.SessionBean] (ServerService Thread Pool -- 51) Failed to get a connection: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]: javax.resource.ResourceException: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:521)
at support.redhat.jboss.jca.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:61)
...
Caused by: javax.resource.ResourceException: Simulate timeout
at support.redhat.jboss.jca.ManagedConnectionImpl.getConnection(ManagedConnectionImpl.java:61)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:508)
...
{code}
There seems to be a difference in a {{NoTransaction}} and an {{XATransaction}} adapter where {{returnConnection}} is triggered by the {{TxConnectionManagerImpl}}.
{code}
... [BMAN] org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.returnConnection(SemaphoreArrayListManagedConnectionPool.java:-1)
... org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:633)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:456)
... org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionDisconnected(TxConnectionManagerImpl.java:515)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
{code}
For a {{NoTransaction}} adapter, however, the abstract implementation is used:
{code}
... [BMAN] org.jboss.jca.core.connectionmanager.AbstractConnectionManager.managedConnectionDisconnected(AbstractConnectionManager.java:697)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
{code}
The empty implementation for [AbstractConnectionManager.managedConnectionDisconnected|https://github.co...] does nothing so the connection is not returned as it would be for a transactional implementation.
I also see the same issue with IronJacamar 1.4.18.Final so this issue remains in the latest release.
was:
When an exception occurs with a {{NoTransaction}} resource adapter during a {{getConnection}} attempt the pool leaks the connection. The exception (simulating a timeout of the underlying connect attempt) detail is below.
{code}
... WARNING [support.jboss.ejb.session.SessionBean] (ServerService Thread Pool -- 51) Failed to get a connection: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]: javax.resource.ResourceException: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:521)
at support.redhat.jboss.jca.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:61)
...
Caused by: javax.resource.ResourceException: Simulate timeout
at support.redhat.jboss.jca.ManagedConnectionImpl.getConnection(ManagedConnectionImpl.java:61)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:508)
...
{code}
There seems to be a difference in a {{NoTransaction}} and an {{XATransaction}} adapter where {{returnConnection}} is triggered by the {{TxConnectionManagerImpl}}.
{code}
... [BMAN] org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.returnConnection(SemaphoreArrayListManagedConnectionPool.java:-1)
... org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:633)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:456)
... org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionDisconnected(TxConnectionManagerImpl.java:515)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
{code}
For {{NoTransaction}} adapter, however, the abstract implementation is used:
{code}
... [BMAN] org.jboss.jca.core.connectionmanager.AbstractConnectionManager.managedConnectionDisconnected(AbstractConnectionManager.java:697)
... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
{code}
The empty implementation for [AbstractConnectionManager.managedConnectionDisconnected|https://github.co...] does nothing so the connection is not returned as it would be for a transactional implementation.
I also see the same issue with IronJacamar 1.4.18.Final so this issue remains in the latest release.
> Connection leak when there is an exception during getConnection for NoTransaction resource adapter
> --------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1398
> URL: https://issues.jboss.org/browse/JBJCA-1398
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.31.Final, 1.0.38.Final, 1.4.10
> Reporter: Stephen Fikes
> Priority: Major
>
> When an exception occurs with a {{NoTransaction}} resource adapter during a {{getConnection}} attempt the pool leaks the connection. The exception (simulating a timeout of the underlying connect attempt) detail is below.
> {code}
> ... WARNING [support.jboss.ejb.session.SessionBean] (ServerService Thread Pool -- 51) Failed to get a connection: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]: javax.resource.ResourceException: IJ000456: Unchecked throwable in ManagedConnection.getConnection() cl=org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@1a933f80[state=NORMAL managed connection=support.redhat.jboss.jca.ManagedConnectionImpl@7a294431 connection handles=0 lastUse=1575419355891 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@1d6a5362 pool internal context=SemaphoreArrayListManagedConnectionPool@2f47607f[pool=EisConnectionFactory]]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:521)
> at support.redhat.jboss.jca.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:61)
> ...
> Caused by: javax.resource.ResourceException: Simulate timeout
> at support.redhat.jboss.jca.ManagedConnectionImpl.getConnection(ManagedConnectionImpl.java:61)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:508)
> ...
> {code}
> There seems to be a difference in a {{NoTransaction}} and an {{XATransaction}} adapter where {{returnConnection}} is triggered by the {{TxConnectionManagerImpl}}.
> {code}
> ... [BMAN] org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.returnConnection(SemaphoreArrayListManagedConnectionPool.java:-1)
> ... org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:633)
> ... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:456)
> ... org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionDisconnected(TxConnectionManagerImpl.java:515)
> ... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
> {code}
> For a {{NoTransaction}} adapter, however, the abstract implementation is used:
> {code}
> ... [BMAN] org.jboss.jca.core.connectionmanager.AbstractConnectionManager.managedConnectionDisconnected(AbstractConnectionManager.java:697)
> ... org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:525)
> {code}
> The empty implementation for [AbstractConnectionManager.managedConnectionDisconnected|https://github.co...] does nothing so the connection is not returned as it would be for a transactional implementation.
> I also see the same issue with IronJacamar 1.4.18.Final so this issue remains in the latest release.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Andreas Liebscher (Jira)
[ https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin... ]
Andreas Liebscher commented on LOGMGR-263:
------------------------------------------
Sorry, it's vice versa, we had to add `static` to boost performance. I adjusted the description.
Some years ago the common recommandation was to prevent static loggers...
Still there could be problems when using different apps simultaneously, you cannot configure the logger on a per app basis.
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.jboss.org/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8
by Andreas Liebscher (Jira)
[ https://issues.jboss.org/browse/LOGMGR-263?page=com.atlassian.jira.plugin... ]
Andreas Liebscher updated LOGMGR-263:
-------------------------------------
Description:
During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
Please check the VisualVM output as prove of JDKSpecific got slower:
was:
During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `static Logger log = LoggerFactory.getLogger(StatusChangeValidatorFactory.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we removed `static` from some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the removed `static` keyword.
Please check the VisualVM output as prove of JDKSpecific got slower:
Summary: Logger Lookup is much slower as with JDK 8 (was: Static Logger Lookup is much slower as with JDK 8)
> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
> Key: LOGMGR-263
> URL: https://issues.jboss.org/browse/LOGMGR-263
> Project: JBoss Log Manager
> Issue Type: Bug
> Environment: WildFly 17, OpenJDK 11
> Reporter: Andreas Liebscher
> Priority: Major
> Attachments: grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-944?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFCORE-944:
-------------------------------
Fix Version/s: 11.0.0.Beta5
(was: 11.0.0.Beta4)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.jboss.org/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Priority: Major
> Fix For: 11.0.0.Beta5
>
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4485?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4485:
--------------------------------
Fix Version/s: 11.0.0.Beta5
(was: 11.0.0.Beta4)
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: WFCORE-4485
> URL: https://issues.jboss.org/browse/WFCORE-4485
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
> Fix For: 11.0.0.Beta5
>
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months