[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2327:
---------------------------
Fix Version/s: 4.1.2
(was: 4.1.1)
> UNICAST3: create receiver table when non-first message is received first
> ------------------------------------------------------------------------
>
> Key: JGRP-2327
> URL: https://issues.jboss.org/browse/JGRP-2327
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> * A and B
> * B sends 2 messages to A: B1 and B2
> * A receives B2 _before_ B1 (both B1 and B2 are OOB)
> * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B
> * B resends B1, but _not_ B2
> * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered
> h4. Scenario (JGRP-2293):
> * A installs a new view
> * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB
> * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted
> * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs
> h4. Workaround
> * Set GMS.leave_timeout to a higher value (say 8000ms)
> h4. Solution
> * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway
> * However, this requires the first seqno from B *to always be 0*
> --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4154) kie-dmn-core: PMMLInfo NPE when model has null output
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4154?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4154:
--------------------------------
Tester: Jozef Marko
> kie-dmn-core: PMMLInfo NPE when model has null output
> -----------------------------------------------------
>
> Key: DROOLS-4154
> URL: https://issues.jboss.org/browse/DROOLS-4154
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.23.0.Final
> Reporter: Michael Anstis
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: model-2.pmml, model-3.pmml, model-4.pmml, model.pmml
>
>
> During testing of the WB changes for PMML support [~jomarko] found the example PMML files referenced by our KIE documentation failed to have a number of models listed against their document definition.
> On examination {{PMMLInfo.from(..)}} throws a NPE if the PMML model lacks an _output_ (see L#57 that throws the NPE if the model has a {{null}} _output_). I've attached the files [~jomarko] used for his testing.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-3964) EJBAccessException is not returned to remote client
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFLY-3964?page=com.atlassian.jira.plugin.... ]
Jaikiran Pai commented on WFLY-3964:
------------------------------------
FWIW - The reproducer application in the linked github repo works fine against WildFly 16.0.0.Final (of course after updating the pom.xml in that repo to use this version):
{code}
Running de.gedoplan.beantrial.wildflyejbremote.DemoTest
Jun 11, 2019 10:40:56 AM org.jboss.naming.remote.client.InitialContextFactory <clinit>
INFO: WFNAM00025: org.jboss.naming.remote.client.InitialContextFactory is deprecated; new applications should use org.wildfly.naming.client.WildFlyInitialContextFactory instead
Jun 11, 2019 10:40:56 AM org.wildfly.naming.client.Version <clinit>
INFO: WildFly Naming version 1.0.9.Final
Jun 11, 2019 10:40:56 AM org.wildfly.security.Version <clinit>
INFO: ELY00001: WildFly Elytron version 1.8.0.Final
Jun 11, 2019 10:40:56 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.6.5.Final
Jun 11, 2019 10:40:56 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.6.5.Final
Jun 11, 2019 10:40:57 AM org.jboss.threads.Version <clinit>
INFO: JBoss Threads version 2.3.3.Final
Jun 11, 2019 10:40:57 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 5.0.8.Final
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.536 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
{code}
> EJBAccessException is not returned to remote client
> ---------------------------------------------------
>
> Key: WFLY-3964
> URL: https://issues.jboss.org/browse/WFLY-3964
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: Dirk Weil
> Assignee: Panagiotis Sotiropoulos
> Priority: Major
>
> When calling an EJB method with access restrictions via @RolesAllowed from a remote client with unsufficient user priveledges, an EJBAccessException should be returned to the remote caller. WildFly returns a java.io.StreamCorruptedException instead.
> Stacktrace on client:
> {code}
> java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:236)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.restrictedMethod(Unknown Source)
> at de.gedoplan.beantrial.wildflyejbremote.DemoTest.testRestrictedMethod(DemoTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:751)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:55)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:82)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> ... 30 more
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.junit.Assert.assertThat(Assert.java:832)
> at org.junit.rules.ExpectedException.handleException(ExpectedException.java:198)
> at org.junit.rules.ExpectedException.access$500(ExpectedException.java:85)
> at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:177)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4474) Missing path validation of a log file while update path
by Marek Kopecky (Jira)
[ https://issues.jboss.org/browse/WFCORE-4474?page=com.atlassian.jira.plugi... ]
Marek Kopecky commented on WFCORE-4474:
---------------------------------------
"{{C:\server.log" doesn't work (same as "C:\server.log")
{noformat}
[standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\server.log})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <:> at index 69: C:\\Users\\Administrator\\playground\\CD16\\jboss-eap-7.3\\st
andalone\\log\\C:server.log",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path="{{C:\server.log"})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <:> at index 71: C:\\Users\\Administrator\\playground\\CD16\\jboss-eap-7.3\\st
andalone\\log\\{{C:server.log",
"rolled-back" => true
}
[standalone@localhost:9990 /]
{noformat}
> Missing path validation of a log file while update path
> --------------------------------------------------------
>
> Key: WFCORE-4474
> URL: https://issues.jboss.org/browse/WFCORE-4474
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 9.0.0.Beta4
> Reporter: Vratislav Marek
> Assignee: James Perkins
> Priority: Major
>
> After the first successful set of a valid path, you can set an invalid path.
> It is can be relative to that while "relative-to" parameter is overridden, the validator doesn't validate it.
> Discovered on Windows.
> A code block is divided, but it is holding sequence to reproduce.
> _This works as expected._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <
> :> at index 61: D:\\Tests\\clear\\wildfly-17.0.0.Beta1-SNAPSHOT\\standalone\\log\\C:/server.log",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\server.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <
> :> at index 61: D:\\Tests\\clear\\wildfly-17.0.0.Beta1-SNAPSHOT\\standalone\\log\\C:server.log",
> "rolled-back" => true
> }
> {code}
> _Still works as expected. But After this successful write-attribute command, it that changing._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\\server.log})
> {"outcome" => "success"}
> {code}
> *Now there is a problem, it that not works as expected. The validator accepts invalid path.*
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:server.log})
> {"outcome" => "success"}
> {code}
> _But not accept all invalid paths._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:*server.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.nio.file.InvalidPathException: Illegal char <
> *> at index 2: C:*server.log",
> "rolled-back" => true
> }
> {code}
> _Verification if the unsuccessful update changes something. But not._
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\\server.log})
> {"outcome" => "success"}
> {code}
> _Verification if is really set in the property value. Yes_
> {code:bash}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:\\server.log"}
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:server.log"}
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:/server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:/server.log"}
> }
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=file,value={path=C:\server.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=file)
> {
> "outcome" => "success",
> "result" => {"path" => "C:server.log"}
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month