[JBoss JIRA] (DROOLS-5203) Make DMN Validator use generic V&V module for conflicting, misleading, masked and overlapping rows
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-5203?page=com.atlassian.jira.plug... ]
Toni Rikkola updated DROOLS-5203:
---------------------------------
Description: Goal is to merge and reuse the existing generic validator for the issue types in the title. The user should see no difference in the workbench use, but this will help us to reduce reduncancy and improve future V&V coverage for both DMN and DRL at the same time.
> Make DMN Validator use generic V&V module for conflicting, misleading, masked and overlapping rows
> --------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5203
> URL: https://issues.redhat.com/browse/DROOLS-5203
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> Goal is to merge and reuse the existing generic validator for the issue types in the title. The user should see no difference in the workbench use, but this will help us to reduce reduncancy and improve future V&V coverage for both DMN and DRL at the same time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2430:
---------------------------
Fix Version/s: 5.1
(was: 5.0.0.Alpha4)
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5132) DMN Drools TCK runner updates
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5132?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5132:
----------------------------------------
CRITERIA FOR RESOLVING THIS JIRA as of 2020-04-08: revert for kie-dmn-tck to use TCK upstream repo's master branch, might require reverting multiple commits of kie-dmn-tck pom.xml
> DMN Drools TCK runner updates
> -----------------------------
>
> Key: DROOLS-5132
> URL: https://issues.redhat.com/browse/DROOLS-5132
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo.
> Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360
> In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners.
> Example, in case
> * the result from a DMN expression evaluation is null,
> * the TCK expect a null,
> * IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test).
> https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7...
> Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one!
> Now is aligned as explained.
> Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359)
> Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, the commit https://github.com/kiegroup/drools/commit/ca70199cf5edccf5261f153dde3296c... can be reverted.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 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 resolved JBJCA-1403.
-----------------------------------
Resolution: Done
> 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, 3 months
[JBoss JIRA] (JBJCA-1407) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/JBJCA-1407?page=com.atlassian.jira.plugi... ]
Flavia Rainone commented on JBJCA-1407:
---------------------------------------
Thanks for the fix, [~brian.stansberry]!
> Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown
> ---------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1407
> URL: https://issues.redhat.com/browse/JBJCA-1407
> Project: IronJacamar
> Issue Type: Bug
> Reporter: Chao Wang
> Assignee: Flavia Rainone
> Priority: Critical
>
> By upgrading IJ to 1.4.21. Final https://issues.redhat.com/browse/WFLY-1324
> There is a constant error in server shutdown
> {code:xml}
> 12:12:44,713 ERROR [stderr] (ConnectionValidator) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException
> 12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:151)
> 12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1261)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:457)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator$ConnectionValidatorRunner.run(ConnectionValidator.java:317)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JBJCA-1407) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/JBJCA-1407?page=com.atlassian.jira.plugi... ]
Flavia Rainone resolved JBJCA-1407.
-----------------------------------
Resolution: Done
> Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException in server shutdown
> ---------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1407
> URL: https://issues.redhat.com/browse/JBJCA-1407
> Project: IronJacamar
> Issue Type: Bug
> Reporter: Chao Wang
> Assignee: Flavia Rainone
> Priority: Critical
>
> By upgrading IJ to 1.4.21. Final https://issues.redhat.com/browse/WFLY-1324
> There is a constant error in server shutdown
> {code:xml}
> 12:12:44,713 ERROR [stderr] (ConnectionValidator) Exception in thread "ConnectionValidator" java.lang.IllegalMonitorStateException
> 12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:151)
> 12:12:44,714 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1261)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:457)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator$ConnectionValidatorRunner.run(ConnectionValidator.java:317)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 12:12:44,715 ERROR [stderr] (ConnectionValidator) at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-1415) Move away from expensive enum switch
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-1415?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFLY-1415:
----------------------------------------
I don't think my comments stand as much about the topic branches but I think the general pattern for parsing has changed a lot over the last five years so a lot of the newer code shouldn't be as affected by this.
> Move away from expensive enum switch
> ------------------------------------
>
> Key: WFLY-1415
> URL: https://issues.redhat.com/browse/WFLY-1415
> Project: WildFly
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
> Labels: janitor
>
> We use enums and enum switch extensively. These constructs generate many, many additional classes and bloat the code base unnecessarily.
> All cases where we are using enum-based switches for our XML parsers should be converted to use Java 7 String switch instead. The enum values shall be replaced with String constant fields, all enum switches converted to String switches, and all enum types removed from these classes. The net result should be a reduction by dozens if not hundreds of .class files, and possibly a measurable performance boost as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months