[JBoss JIRA] (DROOLS-5668) Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories
by Sylvain Lemoine (Jira)
[ https://issues.redhat.com/browse/DROOLS-5668?page=com.atlassian.jira.plug... ]
Sylvain Lemoine commented on DROOLS-5668:
-----------------------------------------
I made a pull request, I don't know how to properly unit test it, unless adding a previously serialized session in 7.0.0.Final (for instance) in test/resources and deserialize it in a test (which I did for my personal testing). Don't know if it's the kind of binary resources you want to add to the source code... let me know or please provide me some guidance to test it, thanks
> Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5668
> URL: https://issues.redhat.com/browse/DROOLS-5668
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Sylvain Lemoine
> Assignee: Mario Fusco
> Priority: Major
> Attachments: drools-node-memories-serialization.tar.gz
>
>
> Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization
> of node memories. For instance it happens if a serialization has been done with earliest version and accumulate node.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13871 at 9/23/20 3:57 PM:
---------------------------------------------------------------------
[~jbaesner] I have added a test case called EJBSuspendResumeRemoteTestCase to the clustering testsuite and the original fix passes the three tests I have written there which cover the scenarios of:
* performing client invocations on a non-suspended server which is then suspended and resumed
* performing client invocations on a suspended server which is then resumed
* performing invocations continuously in a separate thread while suspending and then resuming each node in the cluster
Please have a look at the test case to see if i'm missing something.
Please also provide a link to your reproducer for local debugging.
was (Author: rachmato):
[~jbaesner] I have added a test case called EJBSuspendResumeRemoteTestCase to the clustering testsuite and the original fix passes the three tests I have written there which cover the scenarios of:
* performing client invocations on a non-suspended server which is then suspended and resumed
* performing client invocations on a suspended server which is then resumed
* performing invocations continuously in a separate thread while suspending and then resuming each node in the cluster
Please have a look at the test case to see if i'm missing something.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Final
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13871 at 9/23/20 3:56 PM:
---------------------------------------------------------------------
[~jbaesner] I have added a test case called EJBSuspendResumeRemoteTestCase to the clustering testsuite and the original fix passes the three tests I have written there which cover the scenarios of:
* performing client invocations on a non-suspended server which is then suspended and resumed
* performing client invocations on a suspended server which is then resumed
* performing invocations continuously in a separate thread while suspending and then resuming each node in the cluster
Please have a look at the test case to see if i'm missing something.
was (Author: rachmato):
[~jbaesner] I have added a test case called EJBSuspendResumeRemoteTestCase to the clustering testsuite and the original fix passes the three tests I have written there which cover the scenarios of:
* performing client invocations on a non-suspended server which is then suspended and resumed
* performing client invocations on a suspended server which is then resumed
* performing invocations continuously in a separate thread while suspending and then resuming each node in the cluster
.
Please have a look at the test case to see if i'm missing something.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Final
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13871:
--------------------------------------------
[~jbaesner] I have added a test case called EJBSuspendResumeRemoteTestCase to the clustering testsuite and the original fix passes the three tests I have written there which cover the scenarios of:
* performing client invocations on a non-suspended server which is then suspended and resumed
* performing client invocations on a suspended server which is then resumed
* performing invocations continuously in a separate thread while suspending and then resuming each node in the cluster
.
Please have a look at the test case to see if i'm missing something.
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Final
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ELY-1707) Running tests on JDK11 for branch 1.6.x
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/ELY-1707?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev updated ELY-1707:
-------------------------------
Summary: Running tests on JDK11 for branch 1.6.x (was: Runing tests on JDK11 for branch 1.6.x )
> Running tests on JDK11 for branch 1.6.x
> ----------------------------------------
>
> Key: ELY-1707
> URL: https://issues.redhat.com/browse/ELY-1707
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Major
>
> On 1.6.x branch I am having trouble to test with JDK11
> {{noformat}}
> git checkout 1.6.x
> . java_oracle_8.sh
> mvn clean test -DskipTests
> . java_oracle_11.sh
> mvn test -Dmaven.main.skip=true
> ...
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module java.corba not found
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 17.427 s
> [INFO] Finished at: 2018-11-05T09:49:17+01:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project wildfly-elytron: ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/mchoma/git-repo/wildfly-elytron && /home/mchoma/app/oracle-jdk-11+28/bin/java -javaagent:/home/mchoma/.m2/repository/org/jmockit/jmockit/1.33/jmockit-1.33.jar --add-modules java.corba,java.sql --illegal-access=permit -Djdk.attach.allowAttachSelf=true -jar /home/mchoma/git-repo/wildfly-elytron/target/surefire/surefirebooter10245887984403962786.jar /home/mchoma/git-repo/wildfly-elytron/target/surefire/surefire10250982648577178380tmp /home/mchoma/git-repo/wildfly-elytron/target/surefire/surefire_04789553250451761755tmp
> ...
> {{noformat}}
> Workaround exists. I havet to redefine {noformat}modular.jdk.args{noformat} from
> {noformat}<modular.jdk.args>--add-modules java.corba,java.sql --illegal-access=permit</modular.jdk.args>{noformat}
> to
> {noformat}-Dmodular.jdk.args="--add-modules java.sql --illegal-access=permit"{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13895) The undertow layer can not deploy deployments without the ee layer
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13895:
---------------------------------------
Summary: The undertow layer can not deploy deployments without the ee layer
Key: WFLY-13895
URL: https://issues.redhat.com/browse/WFLY-13895
Project: WildFly
Issue Type: Bug
Components: Build System, Web (Undertow)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Final
{code:java}
16:35:06,234 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException
at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
at org.jboss.as.ee.component.ComponentRegistry.createInstanceFactory(ComponentRegistry.java:76)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:709)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:276)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
... 6 more
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13802) The undertow layer can not deploy deployments without the ee layer
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13802?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13802:
------------------------------------
Steps to Reproduce:
java -jar ~/src/community/galleon/cli/target/galleon-cli-4.2.6.Final-SNAPSHOT.jar install wildfly:current#21.0.0.Final-SNAPSHOT --layers=undertow,deployment-scanner --dir=wildfly
Then deploy a simple war.
> The undertow layer can not deploy deployments without the ee layer
> ------------------------------------------------------------------
>
> Key: WFLY-13802
> URL: https://issues.redhat.com/browse/WFLY-13802
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 21.0.0.Final
>
>
> {code:java}
> 16:35:06,234 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
> at org.jboss.as.ee.component.ComponentRegistry.createInstanceFactory(ComponentRegistry.java:76)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:709)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:276)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFWIP-359) Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
by Martin Svehla (Jira)
[ https://issues.redhat.com/browse/WFWIP-359?page=com.atlassian.jira.plugin... ]
Martin Svehla commented on WFWIP-359:
-------------------------------------
Probably the manager should be more restrictive and only allow to run commands that are in "available commands" list + status
> Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
> -------------------------------------------------------------------------------------
>
> Key: WFWIP-359
> URL: https://issues.redhat.com/browse/WFWIP-359
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Martin Svehla
> Assignee: Kabir Khan
> Priority: Major
>
> If I run setup first, manager activates XP2 stream. However, if I then use patch-apply to apply XP1 patch, manager lets this action to happen and then thinks both streams are active.
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-73
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream is enabled. You may apply patches both from the JBoss EAP and the JBoss EAP XP patch streams. While enabled the following support policy applies:
> [snip]
> You are currently on JBoss EAP XP 2.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> Available commands in this state are: [remove]
> {code}
> {code}
> $ java -jar manager.jar patch-apply --jboss-home=jboss-eap-7.3 --patch=jboss-eap-xp-1.0.2.GA-redhat-20200911-patch.zip
> {code}
> {code}
> $ java -jar manager.jar status --jboss-home=jboss-eap-7.3
> Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
> The JBoss EAP XP patch stream setup in the JBoss EAP server seems broken.
> Enabled patch streams and their cumulative patch ids:
> - Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
> - Patch stream: 'jboss-eap-xp-1.0'; Cumulative patch id: 'jboss-eap-xp-1.0.2.CP'
> Available commands in this state are: [remove]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFWIP-359) Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
by Martin Svehla (Jira)
Martin Svehla created WFWIP-359:
-----------------------------------
Summary: Server can get to state, where XP2 manager thinks both XP1 and XP2 streams are active
Key: WFWIP-359
URL: https://issues.redhat.com/browse/WFWIP-359
Project: WildFly WIP
Issue Type: Bug
Reporter: Martin Svehla
Assignee: Kabir Khan
If I run setup first, manager activates XP2 stream. However, if I then use patch-apply to apply XP1 patch, manager lets this action to happen and then thinks both streams are active.
{code}
$ java -jar manager.jar status --jboss-home=jboss-eap-73
Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
The JBoss EAP XP patch stream is enabled. You may apply patches both from the JBoss EAP and the JBoss EAP XP patch streams. While enabled the following support policy applies:
[snip]
You are currently on JBoss EAP XP 2.
Enabled patch streams and their cumulative patch ids:
- Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
- Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
Available commands in this state are: [remove]
{code}
{code}
$ java -jar manager.jar patch-apply --jboss-home=jboss-eap-7.3 --patch=jboss-eap-xp-1.0.2.GA-redhat-20200911-patch.zip
{code}
{code}
$ java -jar manager.jar status --jboss-home=jboss-eap-7.3
Starting JBoss EAP XP manager (2.0.0.Final-redhat-20200911).
The JBoss EAP XP patch stream setup in the JBoss EAP server seems broken.
Enabled patch streams and their cumulative patch ids:
- Patch stream: 'JBoss EAP'; Cumulative patch id: 'base'
- Patch stream: 'jboss-eap-xp-2.0'; Cumulative patch id: 'base'
- Patch stream: 'jboss-eap-xp-1.0'; Cumulative patch id: 'jboss-eap-xp-1.0.2.CP'
Available commands in this state are: [remove]
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months