February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1915: --------------------------- Fix Version/s: 3.6.3 > JDBC_PING discovery fails when stale entries are found in the database > ---------------------------------------------------------------------- > > Key: JGRP-1915 > URL: https://issues.jboss.org/browse/JGRP-1915 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Reporter: Patrick Haas > Assignee: Bela Ban > Fix For: 3.6.3 > > > Node: "CHQ-PATRICKH-55008" > Database contains two rows.. other node is dead but was unable to remove the JDBC entry. > 1) JChannel.connect(...) > 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH]) > 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS > 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...) > JDBC pulls the node list from the database table. > Ping Data: > - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server > - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489 > joinInternal is a never-terminating while loop: > - down: Event.FIND_INITIAL_MBRS_EVT > - inspect responses -- no valid join responses > - responses are NOT empty -> does not become singletonMember > - gets all coordinators (none) > - Sorts all nodes by GUID in a TreeSet > - Is first of all joiners? > - No, another joiner is listed first > ... repeat forever > When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4386) EJB annotations ignored if classes are packaged as JBOSS modules

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-4386?page=com.atlassian.jira.plugin.... ] Jan Martiska commented on WFLY-4386: ------------------------------------ Well, I agree that it's confusing. But I suspect there are reasons for it to be that way. For example, if a module contains EJB beans and your application depends on that module, but you want to choose whether the application should deploy those EJBs (including JNDI entries etc.) as if they were part of the application. Because that's what it will do if the app imports annotations from the module. > EJB annotations ignored if classes are packaged as JBOSS modules > ---------------------------------------------------------------- > > Key: WFLY-4386 > URL: https://issues.jboss.org/browse/WFLY-4386 > Project: WildFly > Issue Type: Bug > Components: Class Loading, EJB > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Tihomir Meščić > Assignee: David Lloyd > > I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked. > {code:title=Test.java.java|borderStyle=solid} > @ApplicationException(rollback=true) > public class MyException extends Exception { > {code} > > This exception is packaged in a separate JAR. > > When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked). > However, when this JAR is deployed as a JBOSS module (so, in jboss_folder/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation. > > One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4387) Unable to configure ajaxTimeout in wildfly 8.2_Final

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4387?page=com.atlassian.jira.plugin.... ] Stuart Douglas closed WFLY-4387. -------------------------------- Resolution: Rejected Please use the forum to ask for help. There is nothing in Wildfly that will throw an exception after 10 seconds, most likely it is something in your application. > Unable to configure ajaxTimeout in wildfly 8.2_Final > ---------------------------------------------------- > > Key: WFLY-4387 > URL: https://issues.jboss.org/browse/WFLY-4387 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Environment: OS : Windows 8.1 > WildFly: 8.2_Final > Reporter: Manjunatha KB > Assignee: Jason Greene > Labels: wildfly > > Hi. Am newbie to wildfly. Am facing an issue in getting ajax response as my DB is taking some quite time due to huge data. I guess wildfly is throwing internal server error after exactly 10 seconds of request time. So i need to know is there is any attribute which I need to set in standalone.xml to increase this timeout. Exactly as there is "ajaxTimeOut" in apache Tomcat. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1915: -------------------------------- I don't see where you found that the discovery responses are sorted and the first picked. As a matter of fact, in [1] we add all coordinators of the discovery responses to a list (not a sorted set) and then iterate through that list. So whoever coordinator sent their response first is asked to join the new member. Note that I added shuffling of that list on line 104, so that crashed and not removed coords are skipped randomly. I'll see if I can remove crashed (via kill -9) coordinators automatically, but see [2] for an explanation of why this is difficult. In a nutshell, if we have [A,B,C,D] and this splits into [A,B] and [C,D], and new coords remove od coords' files, then A would remove C.list and C would remove A.list. [1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/... [2] https://github.com/belaban/JGroups/blob/master/doc/design/CloudBasedDisco... > JDBC_PING discovery fails when stale entries are found in the database > ---------------------------------------------------------------------- > > Key: JGRP-1915 > URL: https://issues.jboss.org/browse/JGRP-1915 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Reporter: Patrick Haas > Assignee: Bela Ban > > Node: "CHQ-PATRICKH-55008" > Database contains two rows.. other node is dead but was unable to remove the JDBC entry. > 1) JChannel.connect(...) > 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH]) > 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS > 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...) > JDBC pulls the node list from the database table. > Ping Data: > - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server > - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489 > joinInternal is a never-terminating while loop: > - down: Event.FIND_INITIAL_MBRS_EVT > - inspect responses -- no valid join responses > - responses are NOT empty -> does not become singletonMember > - gets all coordinators (none) > - Sorts all nodes by GUID in a TreeSet > - Is first of all joiners? > - No, another joiner is listed first > ... repeat forever > When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4388) Weld starts also for deployments with "bean-discovery-mode=none".

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-4388?page=com.atlassian.jira.plugin.... ] Tomas Remes updated WFLY-4388: ------------------------------ Attachment: _DEFAULT___DEFAULT__probe-beans-test.war Some test reproducer archiv with bdm="none". > Weld starts also for deployments with "bean-discovery-mode=none". > ----------------------------------------------------------------- > > Key: WFLY-4388 > URL: https://issues.jboss.org/browse/WFLY-4388 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final, 9.0.0.Alpha1 > Reporter: Tomas Remes > Assignee: Jozef Hartinger > Attachments: _DEFAULT___DEFAULT__probe-beans-test.war > > > This seems to me at least unneccessary. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4388) Weld starts also for deployments with "bean-discovery-mode=none".

by Tomas Remes (JIRA)

Tomas Remes created WFLY-4388: --------------------------------- Summary: Weld starts also for deployments with "bean-discovery-mode=none". Key: WFLY-4388 URL: https://issues.jboss.org/browse/WFLY-4388 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 9.0.0.Alpha1, 8.2.0.Final Reporter: Tomas Remes Assignee: Jozef Hartinger This seems to me at least unneccessary. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4387) Unable to configure ajaxTimeout in wildfly 8.2_Final

by Manjunatha KB (JIRA)

Manjunatha KB created WFLY-4387: ----------------------------------- Summary: Unable to configure ajaxTimeout in wildfly 8.2_Final Key: WFLY-4387 URL: https://issues.jboss.org/browse/WFLY-4387 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Environment: OS : Windows 8.1 WildFly: 8.2_Final Reporter: Manjunatha KB Assignee: Jason Greene Hi. Am newbie to wildfly. Am facing an issue in getting ajax response as my DB is taking some quite time due to huge data. I guess wildfly is throwing internal server error after exactly 10 seconds of request time. So i need to know is there is any attribute which I need to set in standalone.xml to increase this timeout. Exactly as there is "ajaxTimeOut" in apache Tomcat. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-385) Add overridable flag to servlet metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBMETA-385?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBMETA-385: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1094248, https://bugzilla.redhat.com/show_bug.cgi?id=1196515 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1094248) > Add overridable flag to servlet metadata > ---------------------------------------- > > Key: JBMETA-385 > URL: https://issues.jboss.org/browse/JBMETA-385 > Project: JBoss Metadata > Issue Type: Enhancement > Components: web > Affects Versions: 7.2.1.Final > Reporter: James Livingston > Assignee: Jean-Frederic Clere > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, I believe we need an additional 'overridable' flag on the servlet metadata which indicates whether ServletContainerInitializers (and other code using servlet dynamic registration) should be allowed to override the servlet. Normally this is not allowed, however JBWeb's internal use of DefaultServlet to handle static resources should be. > This only needs to go into 7, since the Undertow subsystem in Wildfly handles this quite differently, so does not need to pass a flag between components. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database

by Patrick Haas (JIRA)

[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ] Patrick Haas commented on JGRP-1915: ------------------------------------ I understand that this situation looks identical to a network partition. What bothers me is that the behavior is random. New groups are formed solely based on the random GUID that's generated. I'd expect one of two outcomes: - A new node always fails to connect when a stale entry remains in the database - A new node always creates a new cluster, after trying to contact the existing nodes a sufficient number of times (i.e. when max_retries is reached, form a group with a sole member and advertise it). I found the implemented behavior very surprising. Is there some larger deterministic algorithm that I'm not seeing? > JDBC_PING discovery fails when stale entries are found in the database > ---------------------------------------------------------------------- > > Key: JGRP-1915 > URL: https://issues.jboss.org/browse/JGRP-1915 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Reporter: Patrick Haas > Assignee: Bela Ban > > Node: "CHQ-PATRICKH-55008" > Database contains two rows.. other node is dead but was unable to remove the JDBC entry. > 1) JChannel.connect(...) > 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH]) > 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS > 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...) > JDBC pulls the node list from the database table. > Ping Data: > - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server > - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489 > joinInternal is a never-terminating while loop: > - down: Event.FIND_INITIAL_MBRS_EVT > - inspect responses -- no valid join responses > - responses are NOT empty -> does not become singletonMember > - gets all coordinators (none) > - Sorts all nodes by GUID in a TreeSet > - Is first of all joiners? > - No, another joiner is listed first > ... repeat forever > When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1910. ---------------------------- Resolution: Done > MERGE3: Do not lose any members from view during a series of merges > ------------------------------------------------------------------- > > Key: JGRP-1910 > URL: https://issues.jboss.org/browse/JGRP-1910 > Project: JGroups > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.6.3 > > Attachments: SplitMergeTest.java > > > When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable. > This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss. > Removing members from view should be the role of FDx protocols, not MERGEx. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

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 February 2015