[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Abhi Vuyyuru (Jira)
Abhi Vuyyuru created DROOLS-5650:
------------------------------------
Summary: UnsupportedOperationException when using enum in Java 11, works fine in Java 8
Key: DROOLS-5650
URL: https://issues.redhat.com/browse/DROOLS-5650
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.43.1.Final
Reporter: Abhi Vuyyuru
Assignee: Mario Fusco
I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
{{}}
{{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
{{ClassFieldVisitor(final Class< ? > cls,
final boolean includeFinalMethods,
final ClassFieldInspector inspector) \{
super(Opcodes.ASM5);
this.clazz = cls;
this.includeFinalMethods = includeFinalMethods;
this.inspector = inspector;
}}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5649) [DMN XML] Signavio Profile - ZipFunction: parameter do not match
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5649?page=com.atlassian.jira.plug... ]
Matteo Mortari reassigned DROOLS-5649:
--------------------------------------
Assignee: Matteo Mortari (was: Mario Fusco)
> [DMN XML] Signavio Profile - ZipFunction: parameter do not match
> ----------------------------------------------------------------
>
> Key: DROOLS-5649
> URL: https://issues.redhat.com/browse/DROOLS-5649
> Project: Drools
> Issue Type: Bug
> Reporter: Tommy Neubert
> Assignee: Matteo Mortari
> Priority: Minor
>
> h2. 1. Synopsis
> In order to allow the execution of dmn.xml files exported by the Signavio Process Manager, the Signavio Profile ([https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-signavio|h...]) contains all custom made functions.
> The zip-function that is contained in this profile however expects its parameters in a different format then the Signavio Process Manager exports. This causes the parsing/execution of such dmn.xml files to fail. Customers have to manually adjust the xml file in order to get there executions running. This is both inconvenient and error prone and should be fixed.
> h2. 2. Technical Details
> As described above the parameters of the zip-function do not match
> Signavio Process Manager Export:
> {code:java}
> zip(["name", "age"], [names, ages]){code}
> Signavio Profiles expected parameters:
> {code:java}
> zip(["name", "age"], names, ages)
> {code}
> Codepointer:
> [https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-signavio/s...]
> h2. 3. Acceptance Criteria
> # zip-function exported by the Signavio Process Manager should be executable without manual adjustments
> # [backwards compatible]existing dmn.xml files (with manual adjustments) should still be exectuable
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13877) [Regression] java.lang.IllegalArgumentException: invalid null LoadStoreParameter
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/WFLY-13877?page=com.atlassian.jira.plugi... ]
Diana Vilkolakova reassigned WFLY-13877:
----------------------------------------
Assignee: Diana Vilkolakova (was: Darran Lofthouse)
> [Regression] java.lang.IllegalArgumentException: invalid null LoadStoreParameter
> --------------------------------------------------------------------------------
>
> Key: WFLY-13877
> URL: https://issues.redhat.com/browse/WFLY-13877
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 21.0.0.Beta1
> Reporter: Martin Choma
> Assignee: Diana Vilkolakova
> Priority: Major
>
> We started to experience new failure in existing FIPS tests. It is legacy security subsystem configured in FIPS mode and authenticating Undertow.
> It is not related to new version of JDK. I can confirm same tests and JDK pass with WF20, but is not passing on WF21.
> {code}
> 15:48:29,224 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service org.wildfly.core.management.security.realm.HttpsRealm.trust-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.HttpsRealm.trust-manager: Failed to start service
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: invalid null LoadStoreParameter
> at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:821)
> at java.base/java.security.KeyStore.load(KeyStore.java:1513)
> at org.jboss.as.domain-management@13.0.0.Beta5//org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:116)
> at org.jboss.as.domain-management@13.0.0.Beta5//org.jboss.as.domain.management.security.FileTrustManagerService.start(FileTrustManagerService.java:137)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> 15:48:29,236 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("security-realm" => "HttpsRealm")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.HttpsRealm.trust-manager" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: invalid null LoadStoreParameter"}}
> 15:48:29,241 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0190: Step handler org.jboss.as.controller.RestartParentResourceHandlerBase$1@235f68cb for operation add at address [
> ("core-service" => "management"),
> ("security-realm" => "HttpsRealm"),
> ("authentication" => "truststore")
> ] failed -- org.jboss.as.controller.registry.Resource$NoSuchResourceException: WFLYCTL0216: Management resource '[
> ("core-service" => "management"),
> ("security-realm" => "HttpsRealm")
> ]' not found [ "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"security-realm\" => \"HttpsRealm\")
> ]' not found" ]: org.jboss.as.controller.registry.Resource$NoSuchResourceException: WFLYCTL0216: Management resource '[
> ("core-service" => "management"),
> ("security-realm" => "HttpsRealm")
> ]' not found [ "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"security-realm\" => \"HttpsRealm\")
> ]' not found" ]
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.OperationContextImpl.requireChild(OperationContextImpl.java:1274)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:945)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:916)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.OperationContextImpl.readResource(OperationContextImpl.java:890)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.OperationContextImpl.readResource(OperationContextImpl.java:884)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.RestartParentResourceHandlerBase$1$1.handleRollback(RestartParentResourceHandlerBase.java:84)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1567)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1539)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1521)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1478)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1461)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1325)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:877)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:757)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:468)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1413)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:431)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:248)
> at org.wildfly.security.elytron-private@1.13.0.CR4//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:304)
> at org.wildfly.security.elytron-private@1.13.0.CR4//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:248)
> at org.jboss.as.controller@13.0.0.Beta5//org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:240)
> at org.jboss.as.controller(a)13.0.0.Beta5//org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOpTests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 6.513 sec <<< FAILURE! - in com.redhat.eap.qe.fips.standalone.HttpsUndertowTestCase
> com.redhat.eap.qe.fips.standalone.HttpsUndertowTestCase Time elapsed: 6.509 sec <<< ERROR!
> org.wildfly.extras.creaper.core.CommandFailedException: Operation {"operation" => "composite","address" => [],"steps" => [{"operation" => "add","address" => [("core-service" => "management"),("security-realm" => "HttpsRealm")]},{"operation" => "add","address" => [("core-service" => "management"),("security-realm" => "HttpsRealm"),("server-identity" => "ssl")],"keystore-password" => "pass123+","keystore-provider" => "PKCS11"},{"operation" => "add","address" => [("core-service" => "management"),("security-realm" => "HttpsRealm"),("authentication" => "truststore")],"keystore-password" => "pass123+","keystore-path" => "whatever","keystore-provider" => "PKCS11"}]} failed: {"outcome" => "failed","result" => {"step-1" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.HttpsRealm.trust-manager" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: invalid null LoadStoreParameter"}},"rolled-back" => true},"step-2" => {"outcome" => "failed","rolled-back" => true},"step-3" => {"outcome" => "failed","rolled-back" => true}},"failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.HttpsRealm.trust-manager" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: invalid null LoadStoreParameter"}}}},"rolled-back" => true}
> at org.wildfly.extras.creaper.core.online.AutomaticErrorHandlingForCommands.commandFailedWithMessage(AutomaticErrorHandlingForCommands.java:138)
> at org.wildfly.extras.creaper.core.online.AutomaticErrorHandlingForCommands.execute(AutomaticErrorHandlingForCommands.java:60)
> at org.wildfly.extras.creaper.core.online.operations.Operations.batch(Operations.java:167)
> at org.wildfly.extras.creaper.commands.undertow.AddHttpsSecurityRealm.apply(AddHttpsSecurityRealm.java:82)
> at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.apply(OnlineManagementClientImpl.java:136)
> at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.apply(OnlineManagementClientImpl.java:125)
> at com.redhat.eap.qe.fips.standalone.HttpsUndertowTestCase.setupServer(HttpsUndertowTestCase.java:213)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 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 updated the pull request. Could you please try this version out - I have modified the initial module update so that it is only sent out of the server is not suspended. I'm also assuming that deployments will not be processed if the server is suspended, as that would require guarding all the other module update messages in a similar way.
> 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.Beta1
>
>
> 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, 10 months
[JBoss JIRA] (WFCORE-2541) CS, MASK-password must support same MASKED string without SALT and ITERATION as old vaults system.
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-2541?page=com.atlassian.jira.plug... ]
Sonia Zaldana commented on WFCORE-2541:
---------------------------------------
Closed because the JBEAP issue got rejected.
> CS, MASK-password must support same MASKED string without SALT and ITERATION as old vaults system.
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2541
> URL: https://issues.redhat.com/browse/WFCORE-2541
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Priority: Major
>
> MASK-password must support same MASKED string without SALT and ITERATION as old vaults system.
> MASKED password in Elytron has this format
> {code}
> MASK-KAwLfD1BN8WFhZptWsa17G==;12345678;230
> {code}
> But old vault system has SALT and ITERATION as global parameters for all MASK-strings same.
> And you have this format of MASKED password
> {code}
> MASK-KAwLfD1BN8WFhZptWsa17G==
> {code}
> It would be better add there original approach too because of migration...
> Please add there this default option:
> * set SALT and ITERATION default values for using of credential stores. If will be defined MASK-string without SALT and ITERATION then will be used these values.
> * if you use MASK-string;SALT;ITERATION form, then will be used SALT and ITERATION from this.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 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/17/20 9:00 AM:
---------------------------------------------------------------------
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update when the client connects is causing this to happen.
UPDATE: I can see that when a client first connects, the two listeners (cluster topology, module update) are registered and, upon registration, the module update listener sends out the current list of started modules. This needs to be adjusted to check if the server is in a suspended state and if so, not send out any modules.
was (Author: rachmato):
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update when the client connects is causing this to happen.
> 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.Beta1
>
>
> 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, 10 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/17/20 8:44 AM:
---------------------------------------------------------------------
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update when the client connects is causing this to happen.
was (Author: rachmato):
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update when the client connects is causing this to happen.
> 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.Beta1
>
>
> 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, 10 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/17/20 8:43 AM:
---------------------------------------------------------------------
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update when the client connects is causing this to happen.
was (Author: rachmato):
Ok, i'll have look. Thanks for the feedback.
> 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.Beta1
>
>
> 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, 10 months