August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe

by Dennis Reed (JIRA)

Dennis Reed created JGRP-1869: --------------------------------- Summary: TP.registerProbeHandler not thread safe Key: JGRP-1869 URL: https://issues.jboss.org/browse/JGRP-1869 Project: JGroups Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.12 Reporter: Dennis Reed Assignee: Bela Ban TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization. If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers. Access to preregistered_probe_handlers should be synchronized. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3715) Async servlets cause lock timeouts for distributable sessions

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3715?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-3715: --------------------------------- Summary: Async servlets cause lock timeouts for distributable sessions (was: Async servlets cause lock timeouts for distrubutable sessions) > Async servlets cause lock timeouts for distributable sessions > ------------------------------------------------------------- > > Key: WFLY-3715 > URL: https://issues.jboss.org/browse/WFLY-3715 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > This happens because Infinispan's BatchContainer relies on thread locals. We need to use the new Batcher capabilities used by ejb clustering for web clustering. These modules should be refactored so they can share these objects. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3709) Component upgrade to Hibernate Validator 5.1.2.Final for WF 8.2

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3709?page=com.atlassian.jira.plugin.... ] Scott Marlow reassigned WFLY-3709: ---------------------------------- Assignee: Scott Marlow (was: Jason Greene) > Component upgrade to Hibernate Validator 5.1.2.Final for WF 8.2 > --------------------------------------------------------------- > > Key: WFLY-3709 > URL: https://issues.jboss.org/browse/WFLY-3709 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gunnar Morling > Assignee: Scott Marlow > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2879) Remove duplicated code from test cases where custom modules are needed

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFLY-2879?page=com.atlassian.jira.plugin.... ] Pedro Igor updated WFLY-2879: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6577 Affects Version/s: 8.1.0.Final (was: 8.0.0.CR1) > Remove duplicated code from test cases where custom modules are needed > ---------------------------------------------------------------------- > > Key: WFLY-2879 > URL: https://issues.jboss.org/browse/WFLY-2879 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.1.0.Final > Reporter: Pedro Igor > Assignee: Pedro Igor > > When writing some integration tests for the PicketLink subsystem, I've noticed that there is no utility class or API to make easier create and remove custom modules from the modules directory. > There are a few tests with this requirement, and most of them are replicating code. > After discussing with [~kabirkhan], he suggested to open this JIRA to review those test cases and make them use a reusable component to work with custom modules. > I've already wrote a class that I think can satisfy all test cases requiring a custom module. > See https://github.com/pedroigor/wildfly/blob/WFLY-2733/testsuite/integration.... > Usage example: https://github.com/pedroigor/wildfly/blob/WFLY-2733/testsuite/integration... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-44) Logging: Add Schema 1.4 compatibility

by James Perkins (JIRA)

James Perkins created WFCORE-44: ----------------------------------- Summary: Logging: Add Schema 1.4 compatibility Key: WFCORE-44 URL: https://issues.jboss.org/browse/WFCORE-44 Project: WildFly Core Issue Type: Task Security Level: Public (Everyone can see) Components: Logging Reporter: James Perkins Assignee: James Perkins A new schema version of 1.4 is going into EAP 6.3. The schema and support should also be added here. The schema will contain custom-formatter which are in 2.0 for WildFly. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2984) Logging: Add Schema 1.4 compatibility

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2984?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-2984: -------------------------------- Fix Version/s: 8.2.0.CR1 (was: 9.0.0.CR1) > Logging: Add Schema 1.4 compatibility > ------------------------------------- > > Key: WFLY-2984 > URL: https://issues.jboss.org/browse/WFLY-2984 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 8.2.0.CR1 > > > A new schema version of 1.4 is going into EAP 6.3. The schema and support should also be added here. The schema will contain {{custom-formatter}} which are in 2.0 for WildFly. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1309: ----------------------------------------------- Pavel Slavicek <pslavice(a)redhat.com> changed the Status of [bug 1110065|https://bugzilla.redhat.com/show_bug.cgi?id=1110065] from VERIFIED to CLOSED > CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-1309 > URL: https://issues.jboss.org/browse/WFLY-1309 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Environment: wildfly build from a git clone on 2013-05-02 > Reporter: Tom Fonteyne > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > Attachments: host-domain-controller.xml, host-slave.xml > > > Setup two boxes: > - on one, run domain mode (full-ha) -> domain controller > - on the other, configure host.xml to point to the DC, and run the host controller > Now in CLI: > # add the group: > /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets) > # create server and set a prop > batch > /host=slave1/server-config=i1:add(group=slaves,auto-start=false) > /host=slave1/server-config=i1/system-property=env:add(value=dev) > run-batch > results in: > JBAS010839: Operation failed or was rolled back on all servers. > Debugging (on EAP 6.0.1) showed the real reason: > activeStep.response = (org.jboss.dmr.ModelNode) { > "outcome" => "failed", > "failure-description" => "JBAS010850: No handler for operation > composite at address [ > (\"host\" => \"slave1\"), > (\"server\" => \"i1\") > ]", > "rolled-back" => true > } > More debugging led to : > org.jboss.as.controller.AbstractOperationContext > seems to be where the rollback is set. When debugging, I found that the constructor always sets > ModelController.OperationTransactionControl transactionControl > but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() : > // Allow any containing TransactionControl to vote > final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK); > and ref becomes a rollback. > I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful. > But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3304) RemoteDomainConnectionService.fetchDomainWideConfiguration() isn't properly implemented

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3304?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3304: ----------------------------------------------- Pavel Slavicek <pslavice(a)redhat.com> changed the Status of [bug 1093866|https://bugzilla.redhat.com/show_bug.cgi?id=1093866] from VERIFIED to CLOSED > RemoteDomainConnectionService.fetchDomainWideConfiguration() isn't properly implemented > --------------------------------------------------------------------------------------- > > Key: WFLY-3304 > URL: https://issues.jboss.org/browse/WFLY-3304 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final, 8.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.Beta1 > > > The WFLY-2043 implementation is not working correctly because fetching the config from the master without fully registering is not properly implemented. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3349) Pull cosmetic schema changes from EAP to WildFly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3349?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3349: ----------------------------------------------- Pavel Slavicek <pslavice(a)redhat.com> changed the Status of [bug 1097311|https://bugzilla.redhat.com/show_bug.cgi?id=1097311] from VERIFIED to CLOSED > Pull cosmetic schema changes from EAP to WildFly > ------------------------------------------------ > > Key: WFLY-3349 > URL: https://issues.jboss.org/browse/WFLY-3349 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3495) /subsystem=transactions/log-store=log-store type attribute should be read-only

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3495?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3495: ----------------------------------------------- Pavel Slavicek <pslavice(a)redhat.com> changed the Status of [bug 1010847|https://bugzilla.redhat.com/show_bug.cgi?id=1010847] from VERIFIED to CLOSED > /subsystem=transactions/log-store=log-store type attribute should be read-only > ------------------------------------------------------------------------------ > > Key: WFLY-3495 > URL: https://issues.jboss.org/browse/WFLY-3495 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Jason Greene > Fix For: 9.0.0.Beta1 > > > There is non-standard behavior of log-store "address" in jboss-cli. > If you want to change log store type via jboss-cli I suppose that supposed way is via command like: > /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true) > similarly with jdbc store. > But there is a second way how to get name the transaction object store in use: > /subsystem=transactions/log-store=log-store:read-attribute(name=type) > But when you try to set the type via this way: > /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=hornetq) > you'll get operation success > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > but no change in the model is realized. > There should be some info to user that this way is not supported or this way should correctly work. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014