March 2014 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote Transaction Timeout

by Coty Sutherland (JIRA)

[ https://issues.jboss.org/browse/WFLY-2852?page=com.atlassian.jira.plugin.... ] Coty Sutherland commented on WFLY-2852: --------------------------------------- This looks like a duplicate of https://issues.jboss.org/browse/WFLY-2789. > JBoss 7 - EJB Remote Transaction Timeout > ---------------------------------------- > > Key: WFLY-2852 > URL: https://issues.jboss.org/browse/WFLY-2852 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Sofiane Bourguiba > Assignee: David Lloyd > Labels: jboss > > I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase. > The problem is that i can't modify the timeout value. > Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded) > You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493 > Thanks, -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote Transaction Timeout

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2852?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2852: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056585 > JBoss 7 - EJB Remote Transaction Timeout > ---------------------------------------- > > Key: WFLY-2852 > URL: https://issues.jboss.org/browse/WFLY-2852 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Sofiane Bourguiba > Assignee: David Lloyd > Labels: jboss > > I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase. > The problem is that i can't modify the timeout value. > Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded) > You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493 > Thanks, -- 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1797: ----------------------------------------------- Richard Achmatowicz <rachmato(a)redhat.com> changed the Status of [bug 927966|https://bugzilla.redhat.com/show_bug.cgi?id=927966] from NEW to ON_QA > NakackTest testReceptionOfAllMessages fails to receive all messages > ------------------------------------------------------------------- > > Key: JGRP-1797 > URL: https://issues.jboss.org/browse/JGRP-1797 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions. > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > Attachments: stdout.txt > > > This test does the following: > - involves channels A, B, and C where only B and C are senders and all are receivers > - B and C send 1000 multicast messages > - checks that all messages are received and in the correct order > This test is failing intermittently but quite often. -- 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

1
0
0 / 0

[JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols configured with plain text passwords

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1721: -------------------------------- I'm going to close this as the keystore name and password can be injected programmatically > AUTH and ENCRYPT protocols configured with plain text passwords > --------------------------------------------------------------- > > Key: JGRP-1721 > URL: https://issues.jboss.org/browse/JGRP-1721 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > The following parameters of AUTH protocol are stored as plain text: > * keystore_password > The following parameters of ENCRYPT protocol are stored as plain text: > * store_password > * key_password > Example: > {code} > <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/> > {code} > Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628 -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014