October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5591) Client mappings cache should always use REPL

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5591?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5591: ------------------------------- Description: Currently, the cache used for ejb client mappings uses the same cache mode as the cache used for SFSBs. On a 4 node cluster, this results in an extra RPC for half of the requests. The client mappings cache should always use REPL, if the SFSB cache is clustered, and should never use a persistent store. (was: Currently, the cache used for routing information uses the same cache mode as the cache used for web sessions. On a 4 node cluster, this results in an extra RPC for half of the requests. The routing cache should always use REPL, if the web session cache is clustered, and should never use a persistent store.) > Client mappings cache should always use REPL > -------------------------------------------- > > Key: WFLY-5591 > URL: https://issues.jboss.org/browse/WFLY-5591 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, the cache used for ejb client mappings uses the same cache mode as the cache used for SFSBs. On a 4 node cluster, this results in an extra RPC for half of the requests. The client mappings cache should always use REPL, if the SFSB cache is clustered, and should never use a persistent store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-350) Need to be able to access the SecurityDomain wrapped by AbstractMechanismAuthenticationFactory

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-350: ------------------------------------ Summary: Need to be able to access the SecurityDomain wrapped by AbstractMechanismAuthenticationFactory Key: ELY-350 URL: https://issues.jboss.org/browse/ELY-350 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI, HTTP, SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha2 Where services use the AbstractMechanismAuthenticationFactory to provide their authentication mechanisms they also need access to the wrapped SecurityDomain e.g. Later on the same container may need this to obtai the current SecurityIdentity. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5590) Shared object store recovery problem

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5590?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated WFLY-5590: --------------------------------- Affects Version/s: 10.0.0.CR3 > Shared object store recovery problem > ------------------------------------ > > Key: WFLY-5590 > URL: https://issues.jboss.org/browse/WFLY-5590 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 10.0.0.CR3 > Reporter: Hayk Hovsepyan > Assignee: Gytis Trikleris > Priority: Critical > Attachments: Server1.log, Server2.log > > > There is a problem with recovery of crashed transactions on two servers when they share the same object store. > The server which starts the recovery second, has problems with processing the logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5590) Shared object store recovery problem

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5590?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated WFLY-5590: --------------------------------- Steps to Reproduce: Reproduce using two server. On both servers: 1. Configure server1 and server2 with different node identifiers to use standard object store the same directory. Restart the servers. 2. Enlist test XA resource. 3. Enlist JMS XA resource. 4. Prepare both resources. 5. Crash both servers on the entry of test XA resource commit. 6. Restart server1. 7. Restart server2. 8. Process recovery on server1. 9. Process recovery on server2. 10. Test XA resource on server2 is rollback. For the server which recovery is started the second, has test XA resource rolled-back. However JMS XA resource is committed on both servers. Trace logs of both servers are attached. It happens for shared JDBC object store as well. It can be reproduced by crashrec testsuite: 1. Clone the repo: "git clone git://git.app.eng.bos.redhat.com/jbossqe-eap-tests-transactions.git tests-transactions" 2. Change directory: "cd tests-transactions/jbossts/" 3. Run test: "mvn clean verify -Djboss.dist=$JBOSS_HOME -Dtest=SharedStoreLoadTestCase#commitHaltClientServer" Attachment: Server1.log Server2.log > Shared object store recovery problem > ------------------------------------ > > Key: WFLY-5590 > URL: https://issues.jboss.org/browse/WFLY-5590 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Hayk Hovsepyan > Assignee: Tom Jenkinson > Priority: Critical > Attachments: Server1.log, Server2.log > > > There is a problem with recovery of crashed transactions on two servers when they share the same object store. > The server which starts the recovery second, has problems with processing the logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5590) Shared object store recovery problem

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5590?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan reassigned WFLY-5590: ------------------------------------ Assignee: Gytis Trikleris (was: Tom Jenkinson) > Shared object store recovery problem > ------------------------------------ > > Key: WFLY-5590 > URL: https://issues.jboss.org/browse/WFLY-5590 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Hayk Hovsepyan > Assignee: Gytis Trikleris > Priority: Critical > Attachments: Server1.log, Server2.log > > > There is a problem with recovery of crashed transactions on two servers when they share the same object store. > The server which starts the recovery second, has problems with processing the logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5590) Shared object store recovery problem

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created WFLY-5590: ------------------------------------ Summary: Shared object store recovery problem Key: WFLY-5590 URL: https://issues.jboss.org/browse/WFLY-5590 Project: WildFly Issue Type: Bug Components: Transactions Reporter: Hayk Hovsepyan Assignee: Tom Jenkinson Priority: Critical There is a problem with recovery of crashed transactions on two servers when they share the same object store. The server which starts the recovery second, has problems with processing the logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5584) Remove and deprecate profile concept for data-sources

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-5584?page=com.atlassian.jira.plugin.... ] Stefano Maestri commented on WFLY-5584: --------------------------------------- BTW WFLY-5426 should solve problem w/ DEFAULT profile. DEFAULT profile is there exactly to be able to get -ds.xml deployed driver from _installed-driver-list and for standalone configuration. As Harald spotted in PR the concept is used from web console and can't be removed. I suggested to close this issue and eventually open one describing the effective problem with the use case not working w/ current implementation > Remove and deprecate profile concept for data-sources > ----------------------------------------------------- > > Key: WFLY-5584 > URL: https://issues.jboss.org/browse/WFLY-5584 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 10.0.0.Final > > > The datasource subsystem was given the concept of domain profiles in WFLY-3634. This doesn't appear to have been fully implemented as {{-ds.xml}} deployments in domain mode don't work. During the deploy process the profile is passed as {{null}} which results in the profile named {{default}} being used. Essentially this means that {{-ds.xml}} domain deployments would only ever work on a profile named {{default}}. > While debugging the issue it doesn't seem as if the profile concept is even needed for data sources. The subsystem is only registered on servers and a server shouldn't need to know about profiles. > In short the profile concept needs to be removed and the {{profile}} attribute on the result of the {{installed-drivers-list}} operation as well as the {{installed-drivers}} complex attribute needs to be deprecated. The attribute was added for the web console and per https://developer.jboss.org/message/941413#941413 it is not used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-348) Ensure consistent Builder initialisation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-348?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse deleted ELY-348: --------------------------------- > Ensure consistent Builder initialisation > ---------------------------------------- > > Key: ELY-348 > URL: https://issues.jboss.org/browse/ELY-348 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > > Where we have builders ensure they can be instantiated using a static builder() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-349) Ensure consistent Builder initialisation

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-349: ------------------------------------ Summary: Ensure consistent Builder initialisation Key: ELY-349 URL: https://issues.jboss.org/browse/ELY-349 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha2 All builders should be instantiated using a static builder() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-348) Ensure consistent Builder initialisation

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-348: ------------------------------------ Summary: Ensure consistent Builder initialisation Key: ELY-348 URL: https://issues.jboss.org/browse/ELY-348 Project: WildFly Elytron Issue Type: Release Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha2 Where we have builders ensure they can be instantiated using a static builder() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 October 2015