[JBoss JIRA] (DROOLS-2848) Make the Verifier Web Worker connector reusable for different V&V types
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2848?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-2848:
---------------------------------
Description:
Actions needed for this:
* Rename DTable verifier to dtableverifier
* Make a register for web workers that finds the right backend providers with CDI
* Create webworker service into kie-wb-common-verifier-api that delivers the correct web worker files based on the module name.
* Make the drools-wb-verifier-webworker provide the web worker so the the web worker service picks it up.
* Move the actual web worker connection codes from dtables module to kie-wb-common-api and make them generic
was:
Actions needed for this:
* Rename DTable verifier to dtableverifier
* Make a register for web workers that finds the right backend providers with CDI
* Create webworker service into kie-wb-common-verifier-api that delivers the correct web worker files based on the module name.
* Change the Web worker servlet path from "verifier" to "webworker"
* Make the drools-wb-verifier-webworker provide the web worker so the the web worker service picks it up.
* Move the actual web worker connection codes from dtables module to kie-wb-common-api and make them generic
> Make the Verifier Web Worker connector reusable for different V&V types
> -----------------------------------------------------------------------
>
> Key: DROOLS-2848
> URL: https://issues.jboss.org/browse/DROOLS-2848
> Project: Drools
> Issue Type: Task
> Components: DMN Editor, Guided Decision Table Editor, verifier
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Labels: drools-tools
>
> Actions needed for this:
> * Rename DTable verifier to dtableverifier
> * Make a register for web workers that finds the right backend providers with CDI
> * Create webworker service into kie-wb-common-verifier-api that delivers the correct web worker files based on the module name.
> * Make the drools-wb-verifier-webworker provide the web worker so the the web worker service picks it up.
> * Move the actual web worker connection codes from dtables module to kie-wb-common-api and make them generic
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SWSQE-383) Run UI tests and REST tests sequentialy not in parallel
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-383?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-383.
---------------------------------
Resolution: Done
It's done this way now:
stage('Run UI Tests') {
when { environment name: 'RUN_UI_TESTS', value: 'true' }
steps {
script {
b = build(job: 'python-ui-tests-parallel',
parameters: [
[$class: 'StringParameterValue', value: "${params.OS_USERNAME}", name: 'OS_USERNAME'],
[$class: 'StringParameterValue', value: "${params.OS_PASSWORD}", name: 'OS_PASSWORD'],
[$class: 'StringParameterValue', value: "https://${params.OS_HOSTNAME}:${params.OS_PORT}", name: 'OS_URL']
],
propagate: false
).result
if(b != 'SUCCESS') {
currentBuild.result = 'UNSTABLE'
}
}
}
}
stage('REST API tests') {
when { environment name: 'RUN_REST_TESTS', value: 'true' }
steps {
build(job: 'run-python-rest-tests',
parameters: [
[$class: 'StringParameterValue', value: "${params.OS_USERNAME}", name: 'OS_USERNAME'],
[$class: 'StringParameterValue', value: "${params.OS_PASSWORD}", name: 'OS_PASSWORD'],
[$class: 'StringParameterValue', value: "https://${params.OS_HOSTNAME}:${params.OS_PORT}", name: 'OS_URL']
]
)
}
}
> Run UI tests and REST tests sequentialy not in parallel
> -------------------------------------------------------
>
> Key: SWSQE-383
> URL: https://issues.jboss.org/browse/SWSQE-383
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Filip Brychta
> Assignee: Filip Brychta
>
> We are running UI and REST tests in parallel but those tests are not atomic. We need to run it sequentially.
> Here is the main pipeline snippet:
> stage('Run Tests') {$
> parallel {$
> stage('Python UI tests') {$
> when { environment name: 'RUN_UI_TESTS', value: 'true' }$
> steps {$
> build(job: 'run-python-ui-tests',$
> parameters: [$
> [$class: 'StringParameterValue', value: "${params.OS_USERNAME}", name: 'OS_USERNAME'],$
> [$class: 'StringParameterValue', value: "${params.OS_PASSWORD}", name: 'OS_PASSWORD'],$
> [$class: 'StringParameterValue', value: "https://${params.OS_HOSTNAME}:${params.OS_PORT}", name: 'OS_URL'],$
> ]$
> )$
> }$
> }$
> stage('REST API tests') {$
> when { environment name: 'RUN_REST_TESTS', value: 'true' }$
> steps {$
> build(job: 'run-python-rest-tests',$
> parameters: [$
> [$class: 'StringParameterValue', value: "${params.OS_USERNAME}", name: 'OS_USERNAME'],$
> [$class: 'StringParameterValue', value: "${params.OS_PASSWORD}", name: 'OS_PASSWORD'],$
> [$class: 'StringParameterValue', value: "https://${params.OS_HOSTNAME}:${params.OS_PORT}", name: 'OS_URL'],$
> ]$
> )$
> }$
> }$
> }$
> }
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2848) Make the Verifier Web Worker connector reusable for different V&V types
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2848?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-2848:
---------------------------------
Description:
Actions needed for this:
* Rename DTable verifier to dtableverifier
* Make a register for web workers that finds the right backend providers with CDI
* Create webworker service into kie-wb-common-verifier-api that delivers the correct web worker files based on the module name.
* Change the Web worker servlet path from "verifier" to "webworker"
* Make the drools-wb-verifier-webworker provide the web worker so the the web worker service picks it up.
* Move the actual web worker connection codes from dtables module to kie-wb-common-api and make them generic
was:
Actions needed for this:
* Rename DTable verifier to dtableverifier
* Make a register for web workers that finds the right backend providers with CDI
* Create webworker service module into kie-wb-common that delivers the correct web worker files based on the module name. (can be reused by non-verifier web workers)
* Change the Web worker servlet path from "verifier" to "webworker"
* Make the drools-wb-verifier-webworker provide the web worker so the the web worker service picks it up.
> Make the Verifier Web Worker connector reusable for different V&V types
> -----------------------------------------------------------------------
>
> Key: DROOLS-2848
> URL: https://issues.jboss.org/browse/DROOLS-2848
> Project: Drools
> Issue Type: Task
> Components: DMN Editor, Guided Decision Table Editor, verifier
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Labels: drools-tools
>
> Actions needed for this:
> * Rename DTable verifier to dtableverifier
> * Make a register for web workers that finds the right backend providers with CDI
> * Create webworker service into kie-wb-common-verifier-api that delivers the correct web worker files based on the module name.
> * Change the Web worker servlet path from "verifier" to "webworker"
> * Make the drools-wb-verifier-webworker provide the web worker so the the web worker service picks it up.
> * Move the actual web worker connection codes from dtables module to kie-wb-common-api and make them generic
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-65:
---------------------------------
The reproducer passed 50 times in a row. Closing.
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Erich Duda closed WFWIP-65.
---------------------------
Resolution: Done
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-21) [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-21?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor edited comment on WFWIP-21 at 8/22/18 7:03 AM:
-------------------------------------------------------------
I think this one is caused by WFWIP-56. The NPE [~jbertram] reported is due to an empty message body, which returns null on getObject(). There's an issue with the JDBC store (WFWIP-56) where calling open file (For large message in this case) auto creates the file in the DB table. But it appears it;s not thread safe which can result in 2 files being created with the same name, only one has the data. Upon read, the other file is used and so the message body is empty. I believe this issue is already present in 1.5.x so shouldn't be a blocker for the upgrade. [~eduda] can you kick off a run to confirm.
Thanks
was (Author: martyn-taylor):
I think this one is caused by WFWIP-15. The NPE [~jbertram] reported is due to an empty message body, which returns null on getObject(). There's an issue with the JDBC store (WFWIP-15) where calling open file (For large message in this case) auto creates the file in the DB table. But it appears it;s not thread safe which can result in 2 files being created with the same name, only one has the data. Upon read, the other file is used and so the message body is empty. I believe this issue is already present in 1.5.x so shouldn't be a blocker for the upgrade. [~eduda] can you kick off a run to confirm.
Thanks
> [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
> ---------------------------------------------------------------------------------
>
> Key: WFWIP-21
> URL: https://issues.jboss.org/browse/WFWIP-21
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Test scenario:
> * Start cluster A of nodes node-1, node-3
> * Start cluster B of nodes node-2, node-4
> * Send messages to queue on node-1
> * Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database
> * Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database
> * Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages
> * Restart failed server
> * Let MDBs to process remaining messages
> Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in
> Actual Result:
> Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2.
> This looks like broker related regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis tag 2.5.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-21) [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-21?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-21:
------------------------------------
I think this one is caused by WFWIP-15. The NPE [~jbertram] reported is due to an empty message body, which returns null on getObject(). There's an issue with the JDBC store (WFWIP-15) where calling open file (For large message in this case) auto creates the file in the DB table. But it appears it;s not thread safe which can result in 2 files being created with the same name, only one has the data. Upon read, the other file is used and so the message body is empty. I believe this issue is already present in 1.5.x so shouldn't be a blocker for the upgrade. [~eduda] can you kick off a run to confirm.
Thanks
> [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load
> ---------------------------------------------------------------------------------
>
> Key: WFWIP-21
> URL: https://issues.jboss.org/browse/WFWIP-21
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Test scenario:
> * Start cluster A of nodes node-1, node-3
> * Start cluster B of nodes node-2, node-4
> * Send messages to queue on node-1
> * Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database
> * Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database
> * Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages
> * Restart failed server
> * Let MDBs to process remaining messages
> Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in
> Actual Result:
> Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2.
> This looks like broker related regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis tag 2.5.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10890) CLI client in jconsole doesn't work with JDK11
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-10890?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise updated WFLY-10890:
----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/11550
> CLI client in jconsole doesn't work with JDK11
> ----------------------------------------------
>
> Key: WFLY-10890
> URL: https://issues.jboss.org/browse/WFLY-10890
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> CLI client in jconsole doesn't work with JDK11.
> JConsole uses CLI. CLI uses WildFlySecurityManager (Elytron 1.5.4.Final). WildFlySecurityManager uses sun.misc.Unsafe. Unsafe works just with adding of {{--add-modules=jdk.unsupported}} to JConsole:
> {code:diff}
> --- a/jconsole.sh
> +++ b/jconsole.sh
> @@ -79,4 +79,4 @@ CLASSPATH=$CLASSPATH:./bin/client/jboss-cli-client.jar
> echo CLASSPATH $CLASSPATH
>
> cd "$JBOSS_HOME"
> -$JAVA_HOME/bin/jconsole -J-Djava.class.path="$CLASSPATH" "$@"
> +$JAVA_HOME/bin/jconsole -J--add-modules=jdk.unsupported -J-Djava.class.path="$CLASSPATH" "$@"
> \ No newline at end of file
> {code}
> But "jdk.unsupported" module is not a correct fix.
> *Logs:*
> {noformat}
> Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: sun/misc/Unsafe
> at org.wildfly.security.manager.WildFlySecurityManager.<clinit>(WildFlySecurityManager.java:122)
> at org.jboss.as.cli.CommandContextFactory.getInstance(CommandContextFactory.java:41)
> at org.jboss.as.cli.gui.ConnectDialog$2.actionPerformed(ConnectDialog.java:182)
> at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
> at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
> at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
> at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
> at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
> at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
> at java.desktop/java.awt.Component.processMouseEvent(Component.java:6631)
> at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
> at java.desktop/java.awt.Component.processEvent(Component.java:6396)
> at java.desktop/java.awt.Container.processEvent(Container.java:2263)
> at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
> at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
> at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
> at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
> Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 39 more
> {noformat}
> *cc:* [~kabirkhan], [~jamezp], [~darranl], [~mchoma], [~msvehla], [~okotek], [~rsvoboda]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months