[JBoss JIRA] (DROOLS-5065) md5Hash results with line endings \r\n on MaterializedLambda tests on Windows
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5065?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5065:
--------------------------------
Sprint: 2020 Week 07-09 (from Feb 10)
> md5Hash results with line endings \r\n on MaterializedLambda tests on Windows
> -----------------------------------------------------------------------------
>
> Key: DROOLS-5065
> URL: https://issues.redhat.com/browse/DROOLS-5065
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.33.0.Final
> Reporter: Daniel Rosa
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: materialized_lambda_hash.patch, materialized_lambda_jenkins_output.pdf
>
>
> Several testes are failing on org.drools.modelcompiler.util.lambdareplace package due the md5Hash function called on className method on classes which extend MatarializedLamda class because Windows consider \r\n as line endings. So the md5Hash results different hashcodes than the expected on assertions.
> If there is any customer's use case related to this usage, I believe that the software should deal with the compatibility between different operating systems.
> If the hash isn't stored and computed only on runtime, the test approch might be changed to compute the hash on the same way it is in production instead of loading it from stored files. Or a different solution might stood up.
> Failing tests:
> * MaterializedLambdaPredicateTest.createClassWithOneParameter
> * MaterializedLambdaPredicateTest.createClassWithTwoParameters
> * MaterializedLambdaExtractorTest.createExtractor
> * MaterializedLambdaConsequenceTest.createConsequence
> * ExecModelLambdaPostProcessorTest.convertFlowLambdaDoNotConvertConsequenceWhenDrools
> * ExecModelLambdaPostProcessorTest.convertPatternLambda
> If the \r is removed when calling md5Hash function, all testes pass. See the attachment [materialized_lambda_hash.patch].
> Stacktrace here: https://gist.github.com/hellowdan/fc1ceb5b640239a4f284c980540eeaca
> or see the attached file [materialized_lambda_jenkins_output.pdf] for the full output.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Brad Maxwell edited comment on WFCORE-4291 at 2/13/20 8:56 PM:
---------------------------------------------------------------
This is more of a feature request than a fix. The not graceful startup mode option would introduce possible race issues allowing external requests before everything is started. As a workaround you can currently register an mbean notification
{code}
@Override
public void handleNotification(Notification notification, Object handback) {
// Make sure the Thread Context ClassLoader is correct since this is an MBean Callback
ClassLoader previous = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(StartedNotificationListener.class.getClassLoader());
AttributeChangeNotification attributeChangeNotification = (AttributeChangeNotification) notification;
if ("RuntimeConfigurationState".equals(attributeChangeNotification.getAttributeName())) {
if (notification.getSequenceNumber() == 4) {
log.info("Invoking callback");
getManagedExecutorService().submit(new Runnable() {
public void run() {
// invoke http or other external request
}
});
}
} catch (Throwable e) {
e.printStackTrace();
} finally {
Thread.currentThread().setContextClassLoader(previous);
}
}
{code}
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
was (Author: bmaxwell):
This is more of a feature request than a fix. The not graceful startup mode option would introduce possible race issues allowing external requests before everything is started. As a workaround you can currently register an mbean notification
{code}
@Override
public void handleNotification(Notification notification, Object handback) {
// Make sure the Thread Context ClassLoader is correct since this is an MBean Callback
ClassLoader previous = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(StartedNotificationListener.class.getClassLoader());
AttributeChangeNotification attributeChangeNotification = (AttributeChangeNotification) notification;
if ("RuntimeConfigurationState".equals(attributeChangeNotification.getAttributeName())) {
if (notification.getSequenceNumber() == 4 && callback != null) {
log.info("Invoking callback");
getManagedExecutorService().submit(new Runnable() {
public void run() {
// invoke http or other external request
}
});
}
} catch (Throwable e) {
e.printStackTrace();
} finally {
Thread.currentThread().setContextClassLoader(previous);
}
}
{code}
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.redhat.com/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Brian Stansberry
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Brad Maxwell commented on WFCORE-4291:
--------------------------------------
This is more of a feature request than a fix. The not graceful startup mode option would introduce possible race issues allowing external requests before everything is started. As a workaround you can currently register an mbean notification
{code}
@Override
public void handleNotification(Notification notification, Object handback) {
// Make sure the Thread Context ClassLoader is correct since this is an MBean Callback
ClassLoader previous = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(StartedNotificationListener.class.getClassLoader());
AttributeChangeNotification attributeChangeNotification = (AttributeChangeNotification) notification;
if ("RuntimeConfigurationState".equals(attributeChangeNotification.getAttributeName())) {
if (notification.getSequenceNumber() == 4 && callback != null) {
log.info("Invoking callback");
getManagedExecutorService().submit(new Runnable() {
public void run() {
// invoke http or other external request
}
});
}
} catch (Throwable e) {
e.printStackTrace();
} finally {
Thread.currentThread().setContextClassLoader(previous);
}
}
{code}
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.redhat.com/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Brian Stansberry
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Vladimir Grabarchuk (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Vladimir Grabarchuk commented on WFCORE-4291:
---------------------------------------------
Any progress on this at all? Maybe an ETA for the fix?
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.redhat.com/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Brian Stansberry
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBJCA-1403) Make connection Validation (at ConnectionValidator) outside of lock
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/JBJCA-1403?page=com.atlassian.jira.plugi... ]
Flavia Rainone commented on JBJCA-1403:
---------------------------------------
Fix version should be 1.4.21, however the version is not on the list.
> Make connection Validation (at ConnectionValidator) outside of lock
> -------------------------------------------------------------------
>
> Key: JBJCA-1403
> URL: https://issues.redhat.com/browse/JBJCA-1403
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
>
> As can be seen in the following stack trace, connection validation inside the connection validator lock might lock the entire prefill of other pools:
> {code}
> "default task-1122" #4743 prio=5 os_prio=0 tid=0x000000000929f800 nid=0x12067 waiting for monitor entry [0x00007fe6c7305000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:299)
> - waiting to lock <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> "default task-1144" #4839 prio=5 os_prio=0 tid=0x000000000ccca800 nid=0x12718 waiting on condition [0x00007fe6cc532000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000008082b8f8> (a java.util.concurrent.locks.ReentrantLock$FairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.internalRegisterPool(ConnectionValidator.java:185)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.registerPool(ConnectionValidator.java:167)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:196)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
> - locked <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> {code}
> The reason for this is that a new pool must be registered, and currently this operation is being blocked by connection validation. If connection validation is slow, this could compromise other threads creating pools and connections as shown in the example.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBJCA-1402) Failure to set query timeout for validation may result in long blocks of the pool
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/JBJCA-1402?page=com.atlassian.jira.plugi... ]
Flavia Rainone updated JBJCA-1402:
----------------------------------
Issue Type: Feature Request (was: Bug)
> Failure to set query timeout for validation may result in long blocks of the pool
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1402
> URL: https://issues.redhat.com/browse/JBJCA-1402
> Project: IronJacamar
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 1.4.10
> Reporter: Stephen Fikes
> Priority: Major
>
> Validation queries run [without any explicit query timeout|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.4.1...]. If the validation query blocks (as it will with most drivers when a connection is invalid/stale), this can block the entire pool in certain cases (e.g. {{background-validation}} locks the pool during validation). Even with {{validate-on-match}}, the failure to enforce a short timeout can significantly impact time to get a connection if one or more failed connections are found in the pool.
> Setting a driver level query timeout is not a suitable workaround because this impacts normal queries that may be expected to run for significant periods. The timeout for normal queries needs to be different from what is tolerated for validation queries (which should respond nearly instantaneously or else the connection is likely broken).
> Minimally, an explicit query timeout should be supplied.
> It might also be useful if a pool property or perhaps a system property could support a configurable timeout period (e.g. to account for potential latency in some systems). The Apache Tomcat pool supports something of this nature with the [validationQueryTimeout|https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool...] property.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4849) [GSS](7.2.z) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
by Wagner Queiroz (Jira)
Wagner Queiroz created WFCORE-4849:
--------------------------------------
Summary: [GSS](7.2.z) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
Key: WFCORE-4849
URL: https://issues.redhat.com/browse/WFCORE-4849
Project: WildFly Core
Issue Type: Bug
Components: Security
Environment: Windows 7 x64. Java 11: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810022317, mixed mode)
Reporter: Wagner Queiroz
After configuring HTTPS using the following guide: [Enable One-way SSL/TLS for Applications|http://docs.wildfly.org/14/WildFly_Elytron_Security.html#con...], configuration seems ok and server boots fine however an illegal reflective access warning comes up from jar within Elytron:
{color:red}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/D:/wildfly-14.0.1.Final_FleetManager/modules/system/layers/base/org/wildfly/extension/elytron/main/wildfly-elytron-integration-6.0.2.Final.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS()
WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
{color}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months