[JBoss JIRA] (WFLY-13824) Use TimeUtil timeout adjustments in cases of timeout defined on JMS receive
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-13824:
---------------------------------------
Summary: Use TimeUtil timeout adjustments in cases of timeout defined on JMS receive
Key: WFLY-13824
URL: https://issues.redhat.com/browse/WFLY-13824
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Affects Versions: 20.0.1.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
There are several places in testsuite where is omitted usage of {{TimeoutUtil}} to allow adjustment of timeouts. When user defines the property {{-Dtimeout.factor}} when he runs the testsuite the waiting timeout for the JMS receival should be adjusted as well.
This issue comes from issues hit on Narayana CI. The machine is slow and running the WildFly testsuite with the Narayana SNAPSHOTs is unstable because of timeouts are not configurable at many places.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (JGRP-2418) Impedence mismatch between message types and transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2418?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2418:
---------------------------
Description:
When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled differently by each transport:
* UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
* TCP writes the array to the socket's output stream
* TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
was:
When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled diffently by each transport:
* UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
* TCP writes the array to the socket's output stream
* TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
> Impedence mismatch between message types and transports
> -------------------------------------------------------
>
> Key: JGRP-2418
> URL: https://issues.redhat.com/browse/JGRP-2418
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled differently by each transport:
> * UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
> * TCP writes the array to the socket's output stream
> * TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
> In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
> This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (JGRP-1424) TP: use of multiple transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ]
Bela Ban closed JGRP-1424.
--------------------------
Resolution: Won't Do
See comments. We can also revisit this should the need arise to have multiple transports.
> TP: use of multiple transports
> ------------------------------
>
> Key: JGRP-1424
> URL: https://issues.redhat.com/browse/JGRP-1424
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (JGRP-1424) TP: use of multiple transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-1424:
--------------------------------
Thanks for the feedback, Dan!
I'm curious: on what criteria do users typically pick a stack in Infinispan? Cloud -> "cloud", IP multicasting disabled -> "tcp", else "udp"?
You're kind of supporting my arguments against multiple transports. I guess I need to do some more thinking, but I'm inclined to kill this feature for now. Perhaps, one day a scenario will appear that warrants revisiting this...
Cheers,
> TP: use of multiple transports
> ------------------------------
>
> Key: JGRP-1424
> URL: https://issues.redhat.com/browse/JGRP-1424
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test random failure
by Daniel Rosa (Jira)
[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ]
Daniel Rosa updated DROOLS-5620:
--------------------------------
Summary: SerializedPackageMergeTwoSteps2Test random failure (was: SerializedPackageMergeTwoSteps2Test is failing on 7.39.x prod jenkins)
> SerializedPackageMergeTwoSteps2Test random failure
> --------------------------------------------------
>
> Key: DROOLS-5620
> URL: https://issues.redhat.com/browse/DROOLS-5620
> Project: Drools
> Issue Type: Bug
> Reporter: Daniel Rosa
> Assignee: Daniel Rosa
> Priority: Minor
>
> org.drools.compiler.integrationtests.
> SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2
> Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException.
> The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them.
> It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk.
> The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test is failing on 7.39.x prod jenkins
by Daniel Rosa (Jira)
[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ]
Daniel Rosa moved RHDM-1443 to DROOLS-5620:
-------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5620 (was: RHDM-1443)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: (was: BRE)
Environment: (was: Jenkins > KIE > 7.39.x > daily-build-prod >daily-build-prod-pipeline-7.39.x)
QE Status: NEW
> SerializedPackageMergeTwoSteps2Test is failing on 7.39.x prod jenkins
> ---------------------------------------------------------------------
>
> Key: DROOLS-5620
> URL: https://issues.redhat.com/browse/DROOLS-5620
> Project: Drools
> Issue Type: Bug
> Reporter: Daniel Rosa
> Assignee: Daniel Rosa
> Priority: Major
>
> org.drools.compiler.integrationtests.
> SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2
> Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException.
> The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them.
> It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk.
> The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test is failing on 7.39.x prod jenkins
by Daniel Rosa (Jira)
[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ]
Daniel Rosa updated DROOLS-5620:
--------------------------------
Priority: Minor (was: Major)
> SerializedPackageMergeTwoSteps2Test is failing on 7.39.x prod jenkins
> ---------------------------------------------------------------------
>
> Key: DROOLS-5620
> URL: https://issues.redhat.com/browse/DROOLS-5620
> Project: Drools
> Issue Type: Bug
> Reporter: Daniel Rosa
> Assignee: Daniel Rosa
> Priority: Minor
>
> org.drools.compiler.integrationtests.
> SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2
> Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException.
> The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them.
> It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk.
> The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (JGRP-1424) TP: use of multiple transports
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on JGRP-1424:
------------------------------------
One scenario where multiple transports would help is with container images: if we could include both transports in the configuration and select one of them at runtime, then fewer users would need to extend the image with a custom configuration. OTOH the Infinispan configuration already allows a user to include multiple JGroups stacks and select one of them at runtime, so the only gain would be the simplification of our default stacks.
WRT automatically detecting when IP multicasting is available, I agree it's hard to get right. I have created ISPN-12235 to perform a multicast test on startup, but I'm not sure exactly how it's going to work.
I also agree WRT using multiple bind addresses: it's really easy to bind to 0.0.0.0 and block connections on unwanted IPs from the firewall, and users who need more complex rules are probably better off configuring them at the OS level.
> TP: use of multiple transports
> ------------------------------
>
> Key: JGRP-1424
> URL: https://issues.redhat.com/browse/JGRP-1424
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months