[JBoss JIRA] (WFLY-1060) When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1060?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-1060.
------------------------------------
Resolution: Migrated to another ITS
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1125025 for the EAP docs.
> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1060
> URL: https://issues.jboss.org/browse/WFLY-1060
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Jim Tyrrell
> Assignee: Brian Stansberry
> Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address. Instead it binds to localhost 127.0.0.1. It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-1060) When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1060?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1060:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1125025
> When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1060
> URL: https://issues.jboss.org/browse/WFLY-1060
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Jim Tyrrell
> Assignee: Brian Stansberry
> Labels: eap6-req
>
> When starting JBoss as with the following command:
> ./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
> It does not bind to the passed in IP Address. Instead it binds to localhost 127.0.0.1. It should have bound to 192.168.192.139 in this instance.
> Instead I had to pass in the parameter like this:
> ./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
> Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3695) Distributed web session expiration ScheduledExecutorService leaks threads on undeploy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3695?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3695:
-------------------------------
Description: The ScheduledExecutorService employed by the SessionExpirationScheduler uses shutdown() to shutdown the thread pool - however, unless we explicitly setExecuteExistingDelayedTasksAfterShutdownPolicy(false), all scheduled tasks will attempt to execute after shutdown! (was: These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads. Shutdown is also a blocking operation, so Service.stop(...) should be asynchronous.)
> Distributed web session expiration ScheduledExecutorService leaks threads on undeploy
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3695
> URL: https://issues.jboss.org/browse/WFLY-3695
> 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
>
>
> The ScheduledExecutorService employed by the SessionExpirationScheduler uses shutdown() to shutdown the thread pool - however, unless we explicitly setExecuteExistingDelayedTasksAfterShutdownPolicy(false), all scheduled tasks will attempt to execute after shutdown!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3695) Distributed web session expiration ScheduledExecutorService leaks threads on undeploy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3695?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3695:
-------------------------------
Summary: Distributed web session expiration ScheduledExecutorService leaks threads on undeploy (was: SFSB eviction and expiration thread pools don't shutdown cleanly)
> Distributed web session expiration ScheduledExecutorService leaks threads on undeploy
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3695
> URL: https://issues.jboss.org/browse/WFLY-3695
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads. Shutdown is also a blocking operation, so Service.stop(...) should be asynchronous.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3695) SFSB eviction and expiration thread pools don't shutdown cleanly
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3695?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3695:
-------------------------------
Description: These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads. Shutdown is also a blocking operation, so Service.stop(...) should be asynchronous. (was: These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads.)
> SFSB eviction and expiration thread pools don't shutdown cleanly
> ----------------------------------------------------------------
>
> Key: WFLY-3695
> URL: https://issues.jboss.org/browse/WFLY-3695
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads. Shutdown is also a blocking operation, so Service.stop(...) should be asynchronous.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3695) SFSB eviction and expiration thread pools don't shutdown cleanly
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3695?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3695:
-------------------------------
Description: These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads. (was: These thread pools currently shutdown via ExecutorService.shutdownNow() but don't , which will leave active threads.)
> SFSB eviction and expiration thread pools don't shutdown cleanly
> ----------------------------------------------------------------
>
> Key: WFLY-3695
> URL: https://issues.jboss.org/browse/WFLY-3695
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> These thread pools currently shutdown via ExecutorService.shutdownNow() but leave active threads.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3695) SFSB eviction and expiration thread pools don't shutdown cleanly
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3695?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3695:
-------------------------------
Description: These thread pools currently shutdown via ExecutorService.shutdownNow() but don't , which will leave active threads. (was: These thread pools currently shutdown via ExecutorService.shutdownNow(), which will leave active threads.)
> SFSB eviction and expiration thread pools don't shutdown cleanly
> ----------------------------------------------------------------
>
> Key: WFLY-3695
> URL: https://issues.jboss.org/browse/WFLY-3695
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> These thread pools currently shutdown via ExecutorService.shutdownNow() but don't , which will leave active threads.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3695) SFSB eviction and expiration thread pools don't shutdown cleanly
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3695:
----------------------------------
Summary: SFSB eviction and expiration thread pools don't shutdown cleanly
Key: WFLY-3695
URL: https://issues.jboss.org/browse/WFLY-3695
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, EJB
Affects Versions: 8.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 8.2.0.CR1, 9.0.0.Beta1
These thread pools currently shutdown via ExecutorService.shutdownNow(), which will leave active threads.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (WFLY-3694) StateHolderSaver behaves incorrectly when object is neither StateHolder nor Serializable
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3694?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3694:
----------------------------------
Please attach a simple reproducer app.
> StateHolderSaver behaves incorrectly when object is neither StateHolder nor Serializable
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-3694
> URL: https://issues.jboss.org/browse/WFLY-3694
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.1.0.Final
> Reporter: Rich DiCroce
> Assignee: Farah Juma
>
> javax.faces.component.StateHolderSaver does not work properly if the object to be saved does not implement Serializable or StateHolder. Such an object will cause the below exception, if the class does not have a public no-arg constructor.
> This issue was already filed with Mojarra as JAVASERVERFACES-1716 by someone else and was closed as Won't Fix. I am not sure why, given that the proposed fix should work and the last comment is completely wrong. But I figure a JBoss developer has a better chance of getting this resolved than I do.
> As a workaround, I am declaring a public no-arg constructor, but that risks someone else using it without understanding why it's there.
> {noformat}
> 2014-07-30 13:55:58,201 ERROR [com.lapis.jsf.framework.ui.exception.FrameworkExceptionHandler] (default task-66) Exception ID 1631720075: javax.faces.FacesException: Unexpected error restoring state for component with id j_idt27:analyzerTable. Cause: java.lang.IllegalStateException: java.lang.InstantiationException: com.sg.song.nms.analyzer.field.ViewElementQueryField.
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:387) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:151) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at org.primefaces.component.api.UIData.visitTree(UIData.java:692) [primefaces-5.0.jar:5.0]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIForm.visitTree(UIForm.java:371) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:367) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:590) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:150) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at org.omnifaces.viewhandler.RestorableViewHandler.restoreView(RestorableViewHandler.java:66) [omnifaces-1.8.1.jar:1.8.1-20140603]
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) [deltaspike-jsf-module-impl-1.0.1.jar:1.0.1]
> at javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:77) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:123) [undertow-websockets-jsr-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> Caused by: java.lang.IllegalStateException: java.lang.InstantiationException: com.sg.song.nms.analyzer.field.ViewElementQueryField
> at javax.faces.component.StateHolderSaver.restore(StateHolderSaver.java:153) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.ComponentStateHelper.restoreState(ComponentStateHelper.java:306) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1621) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at javax.faces.component.UIData.restoreState(UIData.java:1750) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy$2.visit(FaceletPartialStateManagementStrategy.java:380) [jsf-impl-2.2.6-jbossorg-4.jar:]
> ... 54 more
> Caused by: java.lang.InstantiationException: com.sg.song.nms.analyzer.field.ViewElementQueryField
> at java.lang.Class.newInstance(Class.java:418) [rt.jar:1.8.0_05]
> at javax.faces.component.StateHolderSaver.restore(StateHolderSaver.java:150) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
> ... 58 more
> Caused by: java.lang.NoSuchMethodException: com.sg.song.nms.analyzer.field.ViewElementQueryField.<init>()
> at java.lang.Class.getConstructor0(Class.java:2971) [rt.jar:1.8.0_05]
> at java.lang.Class.newInstance(Class.java:403) [rt.jar:1.8.0_05]
> ... 59 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months