March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4389) Upgrade HAL to 2.6.5.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-4389?page=com.atlassian.jira.plugin.... ] Harald Pehl deleted WFLY-4389: ------------------------------ > Upgrade HAL to 2.6.5.Final > -------------------------- > > Key: WFLY-4389 > URL: https://issues.jboss.org/browse/WFLY-4389 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Harald Pehl > Assignee: Harald Pehl > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1244) LocalXAResourceImpl returns RBROLLBACK in certain scenarios which violate the XA specification

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1244?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1244: ------------------------------------------------ Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1181132|https://bugzilla.redhat.com/show_bug.cgi?id=1181132] from ON_QA to VERIFIED > LocalXAResourceImpl returns RBROLLBACK in certain scenarios which violate the XA specification > ---------------------------------------------------------------------------------------------- > > Key: JBJCA-1244 > URL: https://issues.jboss.org/browse/JBJCA-1244 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.0.30.Final > Reporter: Tom Jenkinson > Assignee: Jesper Pedersen > Fix For: 1.0.31.Final, 1.2.3.Final > > > The XA specification states the following about the RBROLLBACK error code for xa_commit(): > {quote} > [XA_RB∗] > The resource manager did not commit the work done on behalf of the transaction branch. Upon return, the resource manager has rolled back the branch’s work and has released all held resources. These values may be returned only if TMONEPHASE is set in flags: > [XA_RBROLLBACK] > The resource manager rolled back the transaction branch for an unspecified reason > {quote} > It is clear that the RBROLLBACK code may only be returned if the branch is known to have rolled back (and indeed if the onePhase flag is set to true). > To cater for scenarios where the XAResource is not able to determine the outcome of the resource managers commit. In those scenarios the XA specification is clear that the only legal error code to return is: > {quote} > [XAER_RMFAIL] > An error occurred that makes the resource manager unavailable. > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4272) Data inconsistency for CMR when connection is broken after database resource commits

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4272?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4272: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1181132|https://bugzilla.redhat.com/show_bug.cgi?id=1181132] from ON_QA to VERIFIED > Data inconsistency for CMR when connection is broken after database resource commits > ------------------------------------------------------------------------------------ > > Key: WFLY-4272 > URL: https://issues.jboss.org/browse/WFLY-4272 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Tom Jenkinson > Assignee: Jesper Pedersen > > Cloned from: > https://bugzilla.redhat.com/show_bug.cgi?id=1181132 > Ondrej Chaloupka 2015-01-12 08:21:45 EST wrote: > We've found issue for CMR where data inconsistency occurs. This happens when CMR db resource successfully commits but the connection is broken before TM receives confirmation about such state. As connection got broken XAException.XA_RBROLLBACK is thrown and TM decides to rollback whole XA transaction. > That ends in situation where db resource was committed and other XA participants are rollbacked. > This is test flow: > - prepare DB xa resource > - prepare test xa resource > - commit DB xa resource > - DB commits > - before confirmation is received by TM the connection crashes > - jdbc driver returns XAException.XA_RBROLLBACK as connection is down > - doAbort is called for the transaction > - test xa resource is rollbacked > - doForget is called and no information about the inconsistent transaction remains in object store > - recovery manager does nothing -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4389) Upgrade HAL to 2.6.5.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-4389?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-4389: ------------------------------ Summary: Upgrade HAL to 2.6.5.Final (was: Upgrade HAL to 2.6.4.Final) > Upgrade HAL to 2.6.5.Final > -------------------------- > > Key: WFLY-4389 > URL: https://issues.jboss.org/browse/WFLY-4389 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging

by Arsalan Masood (JIRA)

[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ] Arsalan Masood edited comment on WFCORE-478 at 3/3/15 6:59 AM: --------------------------------------------------------------- I agree with Geert and I am facing the same problem (use case). I am using Eclipse and I found a plugin that does something similar to what a tail command does in Linux. So I can configure a DailyRollingFileAppender in log4j and tail it using the Eclipse plugin. That is OK for me for the time being. was (Author: arslnmsd): I agree with Geert and I am facing the same problem (use case). I am using Eclipse and I found a plugin that does something similar to what a tail command does in Linux. That is OK for me for the time being. > log4j ConsoleAppender won't display messages with per-deployment logging > ------------------------------------------------------------------------ > > Key: WFCORE-478 > URL: https://issues.jboss.org/browse/WFCORE-478 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Add the following log4j.properties file to a deployment and try to log. > {code} > # Root logger option > log4j.rootLogger=INFO, stdout > # Direct log messages to stdout > log4j.appender.stdout=org.apache.log4j.ConsoleAppender > log4j.appender.stdout.Target=System.out > log4j.appender.stdout.layout=org.apache.log4j.PatternLayout > log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging

by Arsalan Masood (JIRA)

[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ] Arsalan Masood commented on WFCORE-478: --------------------------------------- I agree with Geert and I am facing the same problem (use case). I am using Eclipse and I found a plugin that does something similar to what a tail command does in Linux. That is OK for me for the time being. > log4j ConsoleAppender won't display messages with per-deployment logging > ------------------------------------------------------------------------ > > Key: WFCORE-478 > URL: https://issues.jboss.org/browse/WFCORE-478 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Add the following log4j.properties file to a deployment and try to log. > {code} > # Root logger option > log4j.rootLogger=INFO, stdout > # Direct log messages to stdout > log4j.appender.stdout=org.apache.log4j.ConsoleAppender > log4j.appender.stdout.Target=System.out > log4j.appender.stdout.layout=org.apache.log4j.PatternLayout > log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging

by Geert Coelmont (JIRA)

[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ] Geert Coelmont commented on WFCORE-478: --------------------------------------- Working with per-deployment configurable ConsoleAppender is IMHO essential for flexible development. Suppose my development environment consists of several projects, each deployed to my local Wildfly server, that share a common utility project (deployed as a Jar in each of the applications). Suppose today I'm working on a single one of these projects and in the context of that I want to debug a class Foo from the utility project. I could add Foo to the log4j.properties of my current project and redeploy only this project. I would then see (in my development env. console) logging generated by Foo only from within this one project. Other deployed projects using Foo would not generate logging and thus not clutter my console output. Currently I'm forced to alter the server's standalone.xml logging section, which impacts all other deployments, causing a lot of output that I don't want to see. This apart from the burden of having to restart the whole server with each change of logging settings. Not sure what alternatives to ConsoleAppender exist that would allow me to do the same. > log4j ConsoleAppender won't display messages with per-deployment logging > ------------------------------------------------------------------------ > > Key: WFCORE-478 > URL: https://issues.jboss.org/browse/WFCORE-478 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Add the following log4j.properties file to a deployment and try to log. > {code} > # Root logger option > log4j.rootLogger=INFO, stdout > # Direct log messages to stdout > log4j.appender.stdout=org.apache.log4j.ConsoleAppender > log4j.appender.stdout.Target=System.out > log4j.appender.stdout.layout=org.apache.log4j.PatternLayout > log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1917) FILE_PING: options to remove zombies

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1917?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1917. ---------------------------- Resolution: Done Added {{remove_old_coords_on_view_change}} and {{remove_all_files_on_view_change}} to {{FILE_PING}}. See the manual for details. > FILE_PING: options to remove zombies > ------------------------------------ > > Key: JGRP-1917 > URL: https://issues.jboss.org/browse/JGRP-1917 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.3 > > > In {{FILE_PING}} and subclasses ({{S3_PING}}, {{GOOGLE_PING}}), coordinators write the files (e.g. {{A.list}} for coord {{A}}). > There's a shutdown hook that removes {{A.list}} when {{A}} crashes. > However, when a coordinator is killed by kill -9, the file {{A.list}} won't get removed. > The problem with this is that new members will read {{A.list}} and get delayed trying to ask {{A}} to join the cluster although {{A}}'s not alive anymore ({{B}} is and created {{B.list}}). > Possible solution: implement a mechanism similar to JGRP-1915 where a coordinator removes *all files* on a view change with leaving members, and then writes its file again. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-1119: ------------------------------------- OK, that max length thing might be an issue then because a Uid looks to be 28 bytes: https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes... The length of the node name is fixed because we use it in the Xid (which imposes a 64 byte limit). You could have a look at how we construct the Xids to see if there are some elements of the Uid that are not required because they may already be in the Xid: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... > Assign an unique NodeID automatically > ------------------------------------- > > Key: WFLY-1119 > URL: https://issues.jboss.org/browse/WFLY-1119 > Project: WildFly > Issue Type: Feature Request > Components: Transactions > Reporter: Clebert Suconic > Assignee: Amos Feng > Priority: Optional > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ] Amos Feng commented on WFLY-1119: --------------------------------- {code} public static final SimpleAttributeDefinition NODE_IDENTIFIER = new SimpleAttributeDefinitionBuilder(CommonAttributes.NODE_IDENTIFIER, ModelType.STRING, true) .setDefaultValue(new ModelNode().set("1")) .setFlags(AttributeAccess.Flag.RESTART_ALL_SERVICES) .setAllowExpression(true) .setValidator(new StringBytesLengthValidator(0,23,true,true)) .build(); {code} So it should remove the default value and if the node-identifier is undefined we need to generate a true uuid and persist in the standalone.xml It looks like the max length for node-name is 24 ? I will take a look at the way to check attributes of other servers. > Assign an unique NodeID automatically > ------------------------------------- > > Key: WFLY-1119 > URL: https://issues.jboss.org/browse/WFLY-1119 > Project: WildFly > Issue Type: Feature Request > Components: Transactions > Reporter: Clebert Suconic > Assignee: Amos Feng > Priority: Optional > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 March 2015