September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5434) HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state

by Mark Wardell (JIRA)

Mark Wardell created WFLY-5434: ---------------------------------- Summary: HttpSession invalidate() throws IllegalStateException: Transaction is not in a valid state Key: WFLY-5434 URL: https://issues.jboss.org/browse/WFLY-5434 Project: WildFly Issue Type: Bug Affects Versions: 10.0.0.CR2 Reporter: Mark Wardell Assignee: Jason Greene Attachments: exception.txt Running standalone HA configuration with single sign on enabled in undertow configuration Two wars deployed each marked as distributable If you login thought one war, then execute sesssion.invalidate() on the other you get the following exception during the invalidate call: 08:55:46,441 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /logoutwar/logout: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=96}, status=3} is not in a valid state to be invoking cache operations on. at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:388) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:357) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230) ... at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:66) at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:68) at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:438) at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:176) at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199) at wf10issue.logoutwar.LogoutServlet.doGet(LogoutServlet.java:27) (full stack trace attached) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to freeze the UI

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.... ] Kabir Khan reassigned WFLY-5290: -------------------------------- Assignee: Paul Ferraro (was: Kabir Khan) > Adding JGroups stack seems to freeze the UI > ------------------------------------------- > > Key: WFLY-5290 > URL: https://issues.jboss.org/browse/WFLY-5290 > Project: WildFly > Issue Type: Bug > Components: Clustering, Domain Management > Reporter: Jan Kašík > Assignee: Paul Ferraro > Priority: Critical > Fix For: 10.0.0.Final > > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to freeze the UI

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-5290: ---------------------------------- Assigned back to Paul since the fix for this will be in WFCORE > Adding JGroups stack seems to freeze the UI > ------------------------------------------- > > Key: WFLY-5290 > URL: https://issues.jboss.org/browse/WFLY-5290 > Project: WildFly > Issue Type: Bug > Components: Clustering, Domain Management > Reporter: Jan Kašík > Assignee: Paul Ferraro > Priority: Critical > Fix For: 10.0.0.Final > > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1022) AliasEntry needs more information than just the PathAddress

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-1022: ---------------------------------- Summary: AliasEntry needs more information than just the PathAddress Key: WFCORE-1022 URL: https://issues.jboss.org/browse/WFCORE-1022 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Kabir Khan Assignee: Kabir Khan Priority: Critical Fix For: 2.0.0.CR6 As mentioned on https://issues.jboss.org/browse/WFLY-5290 [17:58] Kabir Khan: @PaulFerraro For https://issues.jboss.org/browse/WFLY-5290, what should the transport=TRANSPORT alias become? [17:59] Paul Ferraro: @KabirKhan it becomes transport=* [18:00] Kabir Khan: @PaulFerraro That can't map properly, it needs to map onto one resource [18:00] Paul Ferraro: e.g. transport=TRANSPORT,type=UDP becomes transport=UDP [18:00] Kabir Khan: ok, I see in that case I can try to take a look [18:01] Paul Ferraro: so - it needs more context than just the address [18:01] Kabir Khan: and let me guess, that is not available at the moment from AliasEntry [18:01] Paul Ferraro: right -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5180) InfinispanResourceRefTestCase causes NameNotFoundException with security manager

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5180?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5180: ------------------------------------ I see - internally, we should be using a privileged action during construction of the cache components that require reflection. > InfinispanResourceRefTestCase causes NameNotFoundException with security manager > -------------------------------------------------------------------------------- > > Key: WFLY-5180 > URL: https://issues.jboss.org/browse/WFLY-5180 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Paul Ferraro > > *Description of problem:* > InfinispanResourceRefTestCase causes NameNotFoundException with security manager. > *How reproducible:* > Always > *Steps to Reproduce:* > # ./build.sh -DskipTests -DallTests -Dts.noSmoke > # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=InfinispanResourceRefTestCase > *Actual results:* > {noformat} > javax.naming.NameNotFoundException: infinispan > at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58) > at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase.test(InfinispanResourceRefTestCase.java:64) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to freeze the UI

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-5290: ---------------------------------- [17:58] Kabir Khan: @PaulFerraro For https://issues.jboss.org/browse/WFLY-5290, what should the transport=TRANSPORT alias become? [17:59] Paul Ferraro: @KabirKhan it becomes transport=* [18:00] Kabir Khan: @PaulFerraro That can't map properly, it needs to map onto one resource [18:00] Paul Ferraro: e.g. transport=TRANSPORT,type=UDP becomes transport=UDP [18:00] Kabir Khan: ok, I see in that case I can try to take a look [18:01] Paul Ferraro: so - it needs more context than just the address [18:01] Kabir Khan: and let me guess, that is not available at the moment from AliasEntry [18:01] Paul Ferraro: right > Adding JGroups stack seems to freeze the UI > ------------------------------------------- > > Key: WFLY-5290 > URL: https://issues.jboss.org/browse/WFLY-5290 > Project: WildFly > Issue Type: Bug > Components: Clustering, Domain Management > Reporter: Jan Kašík > Assignee: Kabir Khan > Priority: Critical > Fix For: 10.0.0.Final > > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to freeze the UI

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.... ] Kabir Khan reassigned WFLY-5290: -------------------------------- Assignee: Kabir Khan (was: Paul Ferraro) > Adding JGroups stack seems to freeze the UI > ------------------------------------------- > > Key: WFLY-5290 > URL: https://issues.jboss.org/browse/WFLY-5290 > Project: WildFly > Issue Type: Bug > Components: Clustering, Domain Management > Reporter: Jan Kašík > Assignee: Kabir Khan > Priority: Critical > Fix For: 10.0.0.Final > > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5433) CommandDispatcher can throw InvalidClassException if command class is not available

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5433: ---------------------------------- Summary: CommandDispatcher can throw InvalidClassException if command class is not available Key: WFLY-5433 URL: https://issues.jboss.org/browse/WFLY-5433 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR2 Reporter: Paul Ferraro Assignee: Paul Ferraro When CommandDispatcher is used by a deployment, the command class might not be available if the deployment is not deployed. Normally, this is prevented by returning a NoSuchService response if the service is unknown, however, this happens *after* the command is unmarshalled. This check should happen before we attempt to unmarshall the command, avoiding unnecessary InvalidClassException. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5340: ----------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from ASSIGNED to POST > Unable to specify module when specifying custom JACC policy class. > ------------------------------------------------------------------ > > Key: WFLY-5340 > URL: https://issues.jboss.org/browse/WFLY-5340 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.CR1 > > > It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module. > From the JACC specification: - > _For each JRE of a J2EE 1.4 or later version Java EE application server, if the > system property > “javax.security.jacc.policy.provider > ” is defined, > the application server must construct an > instance of the class identified by the > system property, confirm that the > resulting object is an instance of > java.security.Policy, > and set, by calling the > java.security.Policy.setPolicy > method, the resulting object as the > corresponding Policy object u > sed by the JRE. _ > The specification only specifies that the system property identifies the class, it does not specify how. > In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1844) Remove shared transport

by Rich DiCroce (JIRA)

[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ] Rich DiCroce commented on JGRP-1844: ------------------------------------ The situation I am in is that two applications share some Infinispan caches, but also have some of their own independent caches. The short explanation is that I have to create three separate cache managers (one shared, one for each application), each of which requires its own JGroups channel. Infinispan assumes that every node in the view is participating in the cache manager, which isn't true for the app-specific cache managers when using a fork channel. That is arguably more of an Infinispan problem, and I'm going to file some issues in the Infinispan JIRA for those, but I don't know if or when those issues will ever be resolved. Shared transport is a useful workaround in the meantime. I also have my own fork channel that is used by only one of the two applications, and I need to be able to determine a coordinator within that subset of members. JGroups currently doesn't do anything to help with that, so instead of forking the channel that is shared by both applications, I'm forking the app-specific channel. It would be nice if JGroups did something for applications using fork channels, so the application can easily determine which cluster members are participating in the fork. Alternatively, is it possible to put the FORK protocol lower in the stack, below the GMS protocol? Then forks would have their own separate views. I haven't tried that but I doubt it would work based on what I've read. > Remove shared transport > ----------------------- > > Key: JGRP-1844 > URL: https://issues.jboss.org/browse/JGRP-1844 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2]. > Here's my reasoning: > * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller > * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared > * TUNNEL doesn't work with shared transports (throws an exception) > * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used > * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste > Thoughts ? My +100 for removing shared transports in 4.0... > [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport > [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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