April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5820) Rename urn:delivery-active schema namespace to urn:delivery

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-5820?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-5820: ---------------------------------- Assignee: Cheng Fang (was: Paul Ferraro) > Rename urn:delivery-active schema namespace to urn:delivery > ----------------------------------------------------------- > > Key: WFLY-5820 > URL: https://issues.jboss.org/browse/WFLY-5820 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Cheng Fang > Priority: Major > > This schema is no longer just used for the delivery active flag, but also for associating a delivery group. The current schema name is confusing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11945) Support clean/graceful undeploy

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-11945: ------------------------------------- Summary: Support clean/graceful undeploy Key: WFLY-11945 URL: https://issues.jboss.org/browse/WFLY-11945 Project: WildFly Issue Type: Feature Request Components: Management Affects Versions: 16.0.0.Final Reporter: Radoslav Husar Assignee: Jeff Mesnil Currently we only support clean/graceful undeploy this placeholder issue is to support clean/graceful undeploy. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5820) Rename urn:delivery-active schema namespace to urn:delivery

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-5820?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5820: ------------------------------- Component/s: (was: Clustering) > Rename urn:delivery-active schema namespace to urn:delivery > ----------------------------------------------------------- > > Key: WFLY-5820 > URL: https://issues.jboss.org/browse/WFLY-5820 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > This schema is no longer just used for the delivery active flag, but also for associating a delivery group. The current schema name is confusing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5129) WARN WELD-000717:Unable to deactivate context when destroying request

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-5129?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-5129. -------------------------------- Resolution: Out of Date The downstream issue is verified. > WARN WELD-000717:Unable to deactivate context when destroying request > --------------------------------------------------------------------- > > Key: WFLY-5129 > URL: https://issues.jboss.org/browse/WFLY-5129 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Major > > Seen in our HTTP-based failover tests (no matter what failover type: jvmkill/shutdown/undeploy), with *distributed* cache used. > These warning messages occur during the whole test run, more than 1000 times for one server. > {code} > [JBossINF] [0m[33m16:24:59,437 WARN [org.jboss.weld.Servlet] (default task-97) WELD-000717: Unable to deactivate context org.jboss.weld.context.http.HttpRequestContextImpl@24af2edb when destroying request HttpServletRequestImpl [ GET /clusterbench/session ] > {code} > These log messages are often close to the [JBEAP-508 OutdatedTopologyException: Cache not running on node|https://issues.jboss.org/browse/JBEAP-508] errors, maybe they are caused by these OutdatedTopologyExceptions. > Server log: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11049) Quickstart jaxws-retail expected errors section needs to be extended

by Jose Montoya (Jira)

[ https://issues.jboss.org/browse/WFLY-11049?page=com.atlassian.jira.plugin... ] Jose Montoya commented on WFLY-11049: ------------------------------------- Same result > Quickstart jaxws-retail expected errors section needs to be extended > -------------------------------------------------------------------- > > Key: WFLY-11049 > URL: https://issues.jboss.org/browse/WFLY-11049 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Environment: Fedora 28; JDK11 build 11+28 > Reporter: Jan Blizňák > Assignee: Sande Gilda > Priority: Major > Fix For: 17.0.0.Beta1 > > > When jaxws-retail quickstart is executed on JDK11, you may encounter these warnings: > {code:java} > [INFO] --- jaxws-tools-maven-plugin:1.2.2.Final:wsconsume (default) @ jaxws-retail-service --- > [ERROR] /bin/sh: switchml: line 1: syntax error: unexpected end of file > [ERROR] /bin/sh: error importing function definition for `switchml' > [ERROR] /bin/sh: _moduleraw: line 1: syntax error: unexpected end of file > [ERROR] /bin/sh: error importing function definition for `_moduleraw' > {code} > This is similar of what is already in expected errors section https://github.com/wildfly/quickstart/blob/master/jaxws-retail/README.adoc, so we might extend the section to be more generic, talking about {{BASH_FUNC_*}}. > The interesting thing is I can see this happening only with JDK11. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5144) OutdatedTopologyException: Node has a newer topology id

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-5144?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-5144. -------------------------------- Resolution: Out of Date Linked issue is verified. > OutdatedTopologyException: Node has a newer topology id > ------------------------------------------------------- > > Key: WFLY-5144 > URL: https://issues.jboss.org/browse/WFLY-5144 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Beta1 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Major > > Seen regularly in our failover tests, with *distributed* cache used. > After failing one node (perf18), perf19 gets a topology update and immediately logs this error: > {code} > [JBossINF] [0m[0m02:58:39,000 INFO [org.infinispan.CLUSTER] (transport-thread--p8-t12) ISPN000310: Starting cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-default.war, topology CacheTopology{id=10, rebalanceId=5, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf19: 30+10, perf20: 24+16, perf21: 26+14]}, pendingCH=DefaultConsistentHash{ns=80, owners = (3)[perf19: 27+26, perf20: 26+28, perf21: 27+26]}, unionCH=null, actualMembers=[perf19, perf20, perf21]} > [JBossINF] [0m[0m02:58:39,002 INFO [org.infinispan.CLUSTER] (transport-thread--p8-t13) ISPN000310: Starting cluster-wide rebalance for cache dist, topology CacheTopology{id=10, rebalanceId=5, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf19: 30+10, perf20: 24+16, perf21: 26+14]}, pendingCH=DefaultConsistentHash{ns=80, owners = (3)[perf19: 27+26, perf20: 26+28, perf21: 27+26]}, unionCH=null, actualMembers=[perf19, perf20, perf21]} > [JBossINF] [0m[31m02:58:40,293 ERROR [io.undertow.request] (default task-103) UT005023: Exception handling request to /clusterbench/session: org.infinispan.statetransfer.OutdatedTopologyException: Node perf21 has a newer topology id > [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.checkTxCommandResponses(TxDistributionInterceptor.java:263) > [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitLockControlCommand(TxDistributionInterceptor.java:182) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174) > [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireRemoteIfNeeded(PessimisticLockingInterceptor.java:238) > [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:66) > [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:287) > [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:259) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:360) > [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:345) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103) > [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86) > [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430) > [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427) > [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56) > [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:238) > [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:124) > [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725) > [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367) > [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) > [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231) > [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152) > [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > perf20,21 log the same error, although stating that it is *perf19* that has a newer topology id. > Server logs: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4421) Stabilize and unignore EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-4421?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-4421: -------------------------------------- Still ignored. https://github.com/wildfly/wildfly/blob/7fdf815c0a349500efbc9317bec928791... [~rachmato] Can you validate if the test is still valid? > Stabilize and unignore EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation > ----------------------------------------------------------------------------------------------- > > Key: WFLY-4421 > URL: https://issues.jboss.org/browse/WFLY-4421 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Tomaž Cerar > Assignee: Richard Achmatowicz > Priority: Minor > Labels: testsuite_stability > > Reenable EJBClientClusterConfigurationTestCase which is currently @Ignored. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4421) Stabilize and unignore EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-4421?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-4421: ------------------------------- Priority: Minor (was: Major) > Stabilize and unignore EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation > ----------------------------------------------------------------------------------------------- > > Key: WFLY-4421 > URL: https://issues.jboss.org/browse/WFLY-4421 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Tomaž Cerar > Assignee: Richard Achmatowicz > Priority: Minor > Labels: testsuite_stability > > Reenable EJBClientClusterConfigurationTestCase which is currently @Ignored. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1951) ha-singleton ElectionPolicy breaks ha-singleton access on deferred startup of second node

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-1951?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-1951. ------------------------------ Resolution: Out of Date > ha-singleton ElectionPolicy breaks ha-singleton access on deferred startup of second node > ----------------------------------------------------------------------------------------- > > Key: WFLY-1951 > URL: https://issues.jboss.org/browse/WFLY-1951 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB, Remoting > Affects Versions: 8.0.0.Alpha4 > Reporter: Thomas Frühbeck > Assignee: Richard Achmatowicz > Priority: Major > > We want to use an election policy for ha-singleton service (SortedElectionPolicy with NamePreference). > To assure, that only the singleton on the preferred node is accessed we also use a DeploymentNodeSelector implementing same preference. > If the second node is started _after_ the first node is in full operation, the ClientContext is not notified of the existence of another node, and does not get the possibility to select the desired node according to cluster policy: > Node "storage" in full operation: > 07:32:30,006 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 3) SELECTOR [storage] > 07:32:30,027 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 3) SELECTOR [storage] > Node "NodeB" startup: > 07:32:35,045 INFO [at.tfr.test.ClusterClient] (EJB default - 2) Service: Proxy for remote EJB StatelessEJBLocator{appName='', moduleName='wildfly-cluster', distinctName='', beanName='ClusterBean', view='interface at.tfr.test.ClusterRemote'} > 07:32:35,048 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 2) SELECTOR [NodeB, storage] > Node "storage": NodeSelector still sees only "storage" > 07:32:35,009 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 4) SELECTOR [storage] > 07:32:35,011 INFO [at.tfr.test.service.ClusterDeploymentNodeSelector] (EJB default - 4) SELECTOR [storage] > If the ElectionPolicy now selected a node other than the currently active one ("NodeB" in this case), the access to the ha-singleton will fail, because "NodeB" is not selectable. > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1416) Cross site replication requires totally connected graph of sites/routes

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-1416?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-1416: ------------------------------- Issue Type: Enhancement (was: Bug) > Cross site replication requires totally connected graph of sites/routes > ------------------------------------------------------------------------ > > Key: WFLY-1416 > URL: https://issues.jboss.org/browse/WFLY-1416 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 8.0.0.Alpha2 > Reporter: Richard Achmatowicz > Assignee: Paul Ferraro > Priority: Major > > Cross site replication is configured using JGroups subsystem <relay/> and <remote-site/> elements to define sites and multicast relay routes between sites. > Looking at a site/route configuration as a graph of nodes and edges, xsite only works if this graph is totally connected (i.e. every site has a defined direct route to every other site). This is because <site name> -> <site id> mappings are assigned per node, with no agreement on what is happening at other nodes. > For example, this configuration works: > <relay site="LON"> > <remote-site name="NYC" .../> > <remote-site name="SFO" .../> > </relay> > <relay site="NYC"> > <remote-site name="LON" .../> > <remote-site name="SFO" .../> > </relay> > <relay site="SFO"> > <remote-site name="NYC" .../> > <remote-site name="LON" .../> > </relay> > but this configuration does not: > <relay site="LON"> > <remote-site name="NYC" .../> > <remote-site name="SFO" .../> > </relay> > <relay site="NYC"> > <remote-site name="LON" .../> > </relay> > <relay site="SFO"> > <remote-site name="LON" .../> > </relay> -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 April 2019