[JBoss JIRA] (DROOLS-5683) Collection editor not opening for DRL based scenarios
by Jan Stastny (Jira)
Jan Stastny created DROOLS-5683:
-----------------------------------
Summary: Collection editor not opening for DRL based scenarios
Key: DROOLS-5683
URL: https://issues.redhat.com/browse/DROOLS-5683
Project: Drools
Issue Type: Bug
Components: Test Scenarios Editor
Affects Versions: 7.44.0.Final
Reporter: Jan Stastny
Assignee: Yeser Amer
Attachments: Screenshot from 2020-09-30 13-42-57.png
DRL based test scenario throws errors when opening Collection editors for lists of some datatypes (didn't do exhaustive search).
* BigDecimal
* LocalDateTime
Unexpected error appears when opening such cell for editing.
{code}
2020-09-30 13:44:09,073 ERROR [org.kie.workbench.common.services.backend.logger.GenericErrorLoggerServiceImpl] (default task-13) Error from user: testadmin Error ID: -1734434608 Location: LibraryPerspective|$ProjectScreen,org.kie.workbench.common.screens.messageconsole.MessageConsole,,,Eorg.docks.PlaceHolder?name=testRunnerReportingPanel,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=2,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=3,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=4,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=5,],,,,,AddAssetsScreen,,,ScenarioSimulationEditor?path_uri=default://master@MySpace/test/src/test/resources/com/myspace/test/test2.scesim&file_name=test2.scesim&has_version_support=true Exception: Uncaught exception: (TypeError) : Cannot read property 'j' of null
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2504 at 9/30/20 7:35 AM:
---------------------------------------------------------
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired. Ditto for {{bla6.java}}, which shows how to do this with ServerSocketChannels. {{bla7}} shows datagram channels.
was (Author: belaban):
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired. Ditto for {{bla6.java}}, which shows how to do this with ServerSocketChannels.
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2504:
---------------------------
Attachment: bla7.java
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java, bla7.java
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 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 commented on WFLY-13877:
------------------------------------------
[~mchoma] The issue that changed this behaviour is fix for WFCORE-944. After this fix, if the path for truststore is specified then the FileTrustManagerService gets initialized instead of ProviderTrustManagerService. FileTrustManagerService attempts to load the keystore on specified path. I think the behaviour now is correct.
> [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)
4 years, 2 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2504 at 9/30/20 7:22 AM:
---------------------------------------------------------
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired. Ditto for {{bla6.java}}, which shows how to do this with ServerSocketChannels.
was (Author: belaban):
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired.
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2504:
---------------------------
Attachment: bla6.java
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java, bla6.java
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2504:
--------------------------------
The attached {{bla5.java}} shows the issue: when line 22 is commented, the receive buffer is not as big as desired.
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2504) Poor throughput over high latency TCP connection when recv_buf_size is configured
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2504?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2504:
---------------------------
Attachment: bla5.java
> Poor throughput over high latency TCP connection when recv_buf_size is configured
> ---------------------------------------------------------------------------------
>
> Key: JGRP-2504
> URL: https://issues.redhat.com/browse/JGRP-2504
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.0.Final
> Reporter: Andrew Skalski
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.1
>
> Attachments: SpeedTest.java, bla5.java
>
>
> I recently finished troubleshooting a unidirectional throughput bottleneck involving a JGroups application (Infinispan) communicating over a high-latency (~45 milliseconds) TCP connection.
> The root cause was JGroups improperly configuring the receive/send buffers on the listening socket. According to the tcp(7) man page:
> {code:java}
> On individual connections, the socket buffer size must be set prior to
> the listen(2) or connect(2) calls in order to have it take effect.
> {code}
> However, JGroups does not set the buffer size on the listening side until after accept().
> The result is poor throughput when sending data from client (connecting side) to server (listening side.) Because the issue is a too-small TCP receive window, throughput is ultimately latency-bound.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months