[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JGRP-1799:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022413
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JGRP-1812) ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1812?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JGRP-1812:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=948762
> ProgrammaticApiTest.testSharedTransport fails to receive correct number of messages
> -----------------------------------------------------------------------------------
>
> Key: JGRP-1812
> URL: https://issues.jboss.org/browse/JGRP-1812
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.14
> Environment: RHEL, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> ProgrammaticApiTest tests the use of the API for creating and configuring channels. One such test testSharedTransport tests the creation and use of a stack with a shared transport. This test does the following:
> - creates two channels A and B
> - creates a UDP-based shared transport stack
> - assigns the same stack to both channels
> - channel A connects to group cluster-one; channel B connects to group cluster-two
> - channel A multicasts 10 messages to its group; channel B multicasts 5 messages to its group
> - the test then waits for the correct number of multicast messages to arrive
> Problem:the test is failing because the receiver on channel A is receiving 20 messages instead of 10 messages.
> This test fails intermittently, but fairly regularly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JGRP-1801:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=927911
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
> Key: JGRP-1801
> URL: https://issues.jboss.org/browse/JGRP-1801
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217)
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-3144:
------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
Still looking into this. Looks like Weld is creating a new session whereas it shouldn't after failover.
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Radoslav Husar
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3179) Dynamic Deployment of Security Domain
by shinzey shinzey (JIRA)
shinzey shinzey created WFLY-3179:
-------------------------------------
Summary: Dynamic Deployment of Security Domain
Key: WFLY-3179
URL: https://issues.jboss.org/browse/WFLY-3179
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.0.0.Final
Environment: WildFly 8.0.0.Final
Reporter: shinzey shinzey
Assignee: Darran Lofthouse
In JBoss 6, security domains can be dynamically deployed using jboss-beans.xml, which is not working in WildFly 8. It would be quite useful to bring back this feature, so that no manual operations or extra scripts are needed to create security domains during application deployment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3178) Update Remoting to 4.0.3.Final
by David Lloyd (JIRA)
David Lloyd created WFLY-3178:
---------------------------------
Summary: Update Remoting to 4.0.3.Final
Key: WFLY-3178
URL: https://issues.jboss.org/browse/WFLY-3178
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Remoting
Reporter: David Lloyd
Assignee: David Lloyd
Priority: Blocker
Fix For: 8.0.1.Final
This update prevents a potentially nasty spin loop (REM3-186).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month