May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6648) InvalidateConversationTestCase(ASYNC-tcp).testInvalidate fails intermittently

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6648: ------------------------------------ Summary: InvalidateConversationTestCase(ASYNC-tcp).testInvalidate fails intermittently Key: WFLY-6648 URL: https://issues.jboss.org/browse/WFLY-6648 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Paul Ferraro test history https://ci.wildfly.org/project.html?projectId=WF&testNameId=8377835033431... test introduced in https://github.com/wildfly/wildfly/pull/6939 {noformat} &amp#27;[0m&amp#27;[0m03:43:53,235 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t16) ISPN000336: Finished cluster-wide rebalance for cache dist, topology id = 1 &amp#27;[0m&amp#27;[0m03:43:53,237 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0002: Started dist cache from ejb container &amp#27;[0m&amp#27;[0m03:43:53,270 INFO [org.infinispan.CLUSTER] (transport-thread--p13-t15) ISPN000336: Finished cluster-wide rebalance for cache routing, topology id = 1 &amp#27;[0m&amp#27;[0m03:43:53,273 INFO [org.infinispan.CLUSTER] (transport-thread--p13-t8) ISPN000336: Finished cluster-wide rebalance for cache conversation.war, topology id = 1 &amp#27;[0m&amp#27;[0m03:43:53,274 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) WFLYCLINF0002: Started conversation.war cache from web container &amp#27;[0m&amp#27;[0m03:43:53,277 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 6) WFLYCLINF0002: Started routing cache from web container &amp#27;[0m&amp#27;[0m03:43:54,675 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 6) WFLYUT0021: Registered web context: /conversation &amp#27;[0m&amp#27;[0m03:43:54,686 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0010: Deployed "conversation.war" (runtime-name : "conversation.war") &amp#27;[0m&amp#27;[0m03:43:54,761 INFO [org.jboss.ejb.client] (default task-1) JBoss EJB Client version 2.1.4.Final &amp#27;[0m&amp#27;[0m03:43:54,799 INFO [stdout] (default task-1) Cache web/conversation.war successfully established view [node-0, node-1] within 0 ms. &amp#27;[0m&amp#27;[31m03:43:54,984 ERROR [io.undertow.request] (default task-20) UT005023: Exception handling request to /conversation/conversation: org.jboss.weld.context.NonexistentConversationException: WELD-000321: No conversation found to restore for id 1 at org.jboss.weld.context.AbstractConversationContext.initialize(AbstractConversationContext.java:240) at org.jboss.weld.context.http.LazyHttpConversationContextImpl.initialize(LazyHttpConversationContextImpl.java:90) at org.jboss.weld.context.http.LazyHttpConversationContextImpl.checkContextInitialized(LazyHttpConversationContextImpl.java:124) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:74) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:114) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90) at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.jboss.as.test.clustering.cluster.web.context.ConversationBean$Proxy$_$$_WeldClientProxy.increment(Unknown Source) at org.jboss.as.test.clustering.cluster.web.context.ConversationServlet.service(ConversationServlet.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-53) Support --runtime-name for deployment on server groups

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-53?page=com.atlassian.jira.plugin.... ] James Perkins closed JBASMP-53. ------------------------------- Resolution: Rejected This isn't going to be done for the {{jboss-as-maven-plugin}}. New features will only go into the [{{wildfly-maven-plugin}}|https://issues.jboss.org/browse/WFMP/]. > Support --runtime-name for deployment on server groups > ------------------------------------------------------ > > Key: JBASMP-53 > URL: https://issues.jboss.org/browse/JBASMP-53 > Project: JBoss AS Maven Plugins > Issue Type: Enhancement > Components: wildfly > Reporter: James Perkins > > The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter). > It would be nice if the JBoss Maven plugin could add another configuration parameter for this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6173. ---------------------------------- Fix Version/s: (was: 10.1.0.Final) Resolution: Duplicate Issue > Classes not unloaded after undeployment > --------------------------------------- > > Key: WFLY-6173 > URL: https://issues.jboss.org/browse/WFLY-6173 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final, 10.0.0.Final > Reporter: Joey Wang > Assignee: Martin Kouba > Priority: Blocker > Attachments: memory-leak.zip > > > I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. > Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances. > Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-36) Consider adding Hot-Deployment option for jboss-as:redeploy goal

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-36?page=com.atlassian.jira.plugin.... ] James Perkins closed JBASMP-36. ------------------------------- Resolution: Rejected This isn't going to be done for the {{jboss-as-maven-plugin}}. New features will only go into the [{{wildfly-maven-plugin}}|https://issues.jboss.org/browse/WFMP/]. > Consider adding Hot-Deployment option for jboss-as:redeploy goal > ---------------------------------------------------------------- > > Key: JBASMP-36 > URL: https://issues.jboss.org/browse/JBASMP-36 > Project: JBoss AS Maven Plugins > Issue Type: Enhancement > Reporter: Samuel Santos > Labels: jboss-as, maven, plugin > > This issue has been previously discussed on GitHub: https://github.com/jbossas/jboss-as-maven-plugin/issues/19 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-70) Hard deploy is not supported

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-70?page=com.atlassian.jira.plugin.... ] James Perkins closed JBASMP-70. ------------------------------- Resolution: Rejected This isn't going to be done for the {{jboss-as-maven-plugin}}. New features will only go into the [{{wildfly-maven-plugin}}|https://issues.jboss.org/browse/WFMP/]. > Hard deploy is not supported > ---------------------------- > > Key: JBASMP-70 > URL: https://issues.jboss.org/browse/JBASMP-70 > Project: JBoss AS Maven Plugins > Issue Type: Feature Request > Reporter: Amal Jose > Priority: Minor > > In Jboss 5 days we used to use a different plugin - which supports jboss hard -deploy i.e it copies the war to location where deployement scaner of jboss is searching a war...advantage of this particular implementation is that JBOSS need not be up for the plugin to run - once the jboss is up, it will take up the war.. > The current implementation does support soft deploy using JBOSS Management API..but there is no hard-deploy goal that used to be supported in JBOSS 5 plugins like http://mojo.codehaus.org/jboss-maven-plugin > Reducing priority as this is possible using other plugins like antrun of maven... > But can JBOSS AS MAVEN plugin support hard deploy (offline Deploy-where jboss instance is not running) > Some online discussions regarding same : http://stackoverflow.com/questions/22936893/jboss-7-x-redeploy-option -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-41) Create goals to add modules do Jboss AS

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-41?page=com.atlassian.jira.plugin.... ] James Perkins closed JBASMP-41. ------------------------------- Resolution: Rejected This isn't going to be done for the {{jboss-as-maven-plugin}}. New features will only go into the [{{wildfly-maven-plugin}}|https://issues.jboss.org/browse/WFMP/]. > Create goals to add modules do Jboss AS > --------------------------------------- > > Key: JBASMP-41 > URL: https://issues.jboss.org/browse/JBASMP-41 > Project: JBoss AS Maven Plugins > Issue Type: Feature Request > Reporter: Gustavo Orair > > A command to create modules using Jboss CLI was created > (refer to https://issues.jboss.org/browse/AS7-4265). > It should be nice if one may create these modules on Jboss server referencing a maven dependency similarly to deploy-artifact configuration section. > Maybe a possible workaround for now should be use execute-commands but it would need to locate where the maven depencies are located: > <execution> > <id>create-modules</id> > <phase>install</phase> > <goals> > <goal>execute-commands</goal> > </goals> > <configuration> > <execute-commands> > <commands> > <command>module add --name=oracle.jdbc --resources=ojdbc6.jar --dependencies=javax.api,javax.transaction.api</command> > </commands> > </execute-commands> > </configuration> > </execution> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-34) Use src/main/webapp with jboss-as:run goal

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-34?page=com.atlassian.jira.plugin.... ] James Perkins closed JBASMP-34. ------------------------------- Resolution: Rejected This isn't going to be done for the {{jboss-as-maven-plugin}}. New features will only go into the {{wildfly-maven-plugin}}. > Use src/main/webapp with jboss-as:run goal > ------------------------------------------ > > Key: JBASMP-34 > URL: https://issues.jboss.org/browse/JBASMP-34 > Project: JBoss AS Maven Plugins > Issue Type: Feature Request > Reporter: James Perkins > > Use {{src/main/webapp}} when the {{mvn jboss-as:run}} goal is performed so CSS/HTML/JS changes will be picked up automatically. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2070) Add flag back to disable individual thread pools

by Bela Ban (JIRA)

Bela Ban created JGRP-2070: ------------------------------ Summary: Add flag back to disable individual thread pools Key: JGRP-2070 URL: https://issues.jboss.org/browse/JGRP-2070 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0 In 4.0, {{xxx_thread_pool.enbled}} was removed. The idea was that this could be done programmatically by using {{TP.setOOBThreadPool()}} using a {{DirectExecutor}}. However, sometimes it is convenient to do this declaratively, in the XML config file, e.g. if the code cannot be changed or the channel cannot be retrieved. Therefore add the attribute(s) to disable/enable thread pools back. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2069) UNICAST3: bypass or remove when running over TCP

by Bela Ban (JIRA)

Bela Ban created JGRP-2069: ------------------------------ Summary: UNICAST3: bypass or remove when running over TCP Key: JGRP-2069 URL: https://issues.jboss.org/browse/JGRP-2069 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.6.10, 4.0 When running over TCP as transport, UNICAST3 is still required: while TCP/IP retransmits messages reliably and also provides sender-FIFO ordering, the receiver's thread pool might be exhausted and thus the message might get rejected. However, *if* the regular and OOB thread pools are disabled, we could actually bypass (or completely remove) UNICAST3. If messages get dropped by a protocol further up the stack, however, there will be no retransmission in this case. SOLUTION: * Document this behavior * Emit an INFO message (or automatically bypass UNICAST3) when run over a TCP transport and both OOB and regular pools are disabled -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1568) AttributeDefinition should defer handling of undefined values to CapabilityReferenceRecorder

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1568?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFCORE-1568: --------------------------------- Summary: AttributeDefinition should defer handling of undefined values to CapabilityReferenceRecorder (was: AttributeDefinition should defer to CapabilityReferenceRecorder for handling null values) > AttributeDefinition should defer handling of undefined values to CapabilityReferenceRecorder > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1568 > URL: https://issues.jboss.org/browse/WFCORE-1568 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.2.0.CR2 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > This allows an attribute to potentially reference some other static named capability if its value is null, as determined by the CapabilityReferenceRecorder implementation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016