[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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:
--------------------------------
The other argument in favor of multiple transports, namely bundling of different network interfaces, can be achieved at the OS level, e.g. by using IP Bonding, and probably at a much higher efficiency than doing this in user-space...
> 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)
5 years, 1 month
[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:
--------------------------------
I'm questioning the usefulness of having multiple transports, against the added complexity...
If we have IP multicasting available, we'd probably use UDP:PING (or TCP:MPING if we don't want to use IP multicasting for sending/receiving of messages, only for discovery).
If IP multicasting is disabled, we'd have to use TCP anyway.
I currently don't see a use case where both UDP *and* TCP would be enabled...
> 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)
5 years, 1 month
[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:
--------------------------------
Hmm, what if we have UDP and TCP, but IP multicasting is not supported? This is hard to find out, as missed messages might be caused by firewalls/VPN policies rather than multicasting itself...
Sending group messages out via UDP would then fail...
> 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)
5 years, 1 month