[JBoss JIRA] (WFCORE-3387) MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3387?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3387:
------------------------------------------
The fact that your bean's bruteForceManagedBeanRegistration() method works is a bug. The mbean doesn't exist at that moment, but our JMX integration is allowing the MBeanServerConnection.addNotificationListener call to succeed, even though the documentation of the interface says that method should throw InstanceNotFoundException
if "[t]he MBean name provided does not match any of the registered MBeans."
During execution of the "deploy" management operation, the mbean does not exist. It only exists when that operation commits and the copy of the server management model maintained locally by the thread executing the management operation publishes the model.
> MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3387
> URL: https://issues.jboss.org/browse/WFCORE-3387
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 3.0.8.Final
> Reporter: Nuno Godinho de Matos
> Priority: Minor
>
> In wildfly, there is a class of managed beans that are particularly useful to have available during application deployment.
> In partocular beans with Object name (e.g. jboss.as:deployment=someapp-war.war)
> This type of beans can for example sned a JMX Notification that the corresponding application has been deployed.
> While trying to refactor a mechanism that fires an "ApplicationDeployed" event, a mechanism that was blinding registering a Listener on a hard coded ObjectName stopped working consistently once I generalized to hunt for the generalized beans.
> The problem is the following.
> 1. HARD CODED APPROACH:
> If when an application is deploying, during the @Startup logic of an EJB I blindly do something like:
> {panel}
> MBeanServer mBeanServer = createMBeanServer();
> ObjectName targetObject = new ObjectName(objectName);
> mBeanServer.addNotificationListener(targetObject, listener, filter, handback);
> {panel}
> I can successfully register my Listener, without any problem.
> This will work 100% of the time, and after the deployment goes through I can send my notification to the application that the deployment is done.
> I just need to blindly register the listener on:
> jboss.as:deployment=someapp-war.war
> 2. PROBLEM - GENERALIZED APPORACH - QUERY MBEANS
> The Problem now is that once I try to generalize the mechanism, instead of directly doing something like jumping at the "registration", first I need to run a JMX query to hunt of beans:
> jboss.as:deployment=*
> Now I have the problem that I am coming out empty handed, no results.
> Better said, the current approach has two possible behaviors.
> Behavior 1 - Mechanism works:
> - Wildfly is stopped
> - on eclipse I drag and drop the WAR file to the APP server.
> - I start wildfly.
> In this case, the jboss.as:deployment=* will give me the deployed applications.
> The generic mechanism works.
> Behavior 2 - Query comes with no results
> - Wildfly is running
> - no deployments
> - I drag and drop the APP,
> then I get no results.
> Here is a Log snippet from the application when running on apporach 2.
> What you is multiple fluent wait queries.
> You have N tries loop where the query * and hard-coded object name is run. In both scenarios I get no results.
> But i still managed to register a listener If I want and I know the war name.
> {panel}
> ####2017-10-27 11:44:10,171 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,246 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,253 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,328 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,332 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,406 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,409 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,490 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,494 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,569 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,574 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,649 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,653 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,726 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,729 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,802 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,804 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,884 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,893 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,967 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,970 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,044 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,050 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,129 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,138 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,217 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,227 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,304 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,312 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,386 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,393 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,472 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,480 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,559 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,568 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,646 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,656 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,736 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,744 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,822 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,831 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,904 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,907 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,985 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - JMX Query to search for app deployments yielded: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - No WAR deployment could be found on the managed bean server. The applicatin runtimes that could be found were: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to add notification listerner using HARD CODED deployment JMX object name <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to register a jmx notification listener on the status of the deployed application: jboss.as:deployment=someapp-war.war <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,994 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Skipping registration of NotificationLister on WAR application runtime, managed bean could not be found.This has the implication that the application ready event will not be fired after the deployment completes. <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,995 ThreadId:512 INFO [WildflyJmxAppDeploymentNotificationListenerRegistration] - <- WildflyJmxAppDeploymentNotificationListenerRegistration.registerNotificationLister {2092 ms} <LogContext:Facade> <ServerService Thread Pool -- 339>
> {panel}
> I can try to create a sample application to reproduce this.
> I would expect that before the @Startup logic is triggered on any EJB, I consistenly will have on the MBean server the deployment managemend bean for the WAR whose deployment is currently ongoing - regardless of whether I start the APP serer with the WAr already in or if I have just added the WAr file.
> And in effect, since the "registration mechanims of a listener always works - if you already know the WAR file name ... then it kind means that the Managed bean is in effect in the MBean serer but somehow not visible.
> Many thanks for any help on this.
> I will try to give you a sample application for analysis.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9510) [GSS](7.2.0) Default SFSB Lifecycle methods transaction attribute causing warnings
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-9510:
----------------------------------
Summary: [GSS](7.2.0) Default SFSB Lifecycle methods transaction attribute causing warnings
Key: WFLY-9510
URL: https://issues.jboss.org/browse/WFLY-9510
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.Final
Reporter: Brad Maxwell
Attachments: warning-reproducer.zip
EJB 2 deployment that does not specify transaction attribute for lifecycle methods such as: ejbActivate, ejbRemove, ejbPassivate are logging this warning.
JBAS014279: Invalid transaction attribute type REQUIRED on SFSB lifecyle method Method ejbRemove(), valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9509) Default SFSB Lifecycle methods transaction attribute causing warnings
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-9509?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-9509:
-------------------------------
Attachment: warning-reproducer.zip
> Default SFSB Lifecycle methods transaction attribute causing warnings
> ---------------------------------------------------------------------
>
> Key: WFLY-9509
> URL: https://issues.jboss.org/browse/WFLY-9509
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Brad Maxwell
> Attachments: warning-reproducer.zip
>
>
> EJB 2 deployment that does not specify transaction attribute for lifecycle methods such as: ejbActivate, ejbRemove, ejbPassivate are logging this warning.
> JBAS014279: Invalid transaction attribute type REQUIRED on SFSB lifecyle method Method ejbRemove(), valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-8656) Bean discovery in deployment dependencies (modules) is always interpreted as "all"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8656?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-8656:
------------------------------------
Assignee: Martin Kouba (was: Stuart Douglas)
> Bean discovery in deployment dependencies (modules) is always interpreted as "all"
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8656
> URL: https://issues.jboss.org/browse/WFLY-8656
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final, 11.0.0.Beta1
> Reporter: Yoann Rodière
> Assignee: Martin Kouba
>
> The CDI spec specifies that the {{beans.xml}} file may set the "bean discovery mode" for a given bean archive: https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
> Possible values include "all" (all classes should be considered as CDI beans) and "annotated" (only classes with class-level CDI annotations should b considered as CDI beans).
> In Wildfly, this bean discovery mode is taken into account correctly for deployments, but not for the modules they depend on. For those modules, provided there is a {{beans.xml}}, and irrespective of the bean discovery mode set inside this file, every single class is considered as a bean and added to the CDI context.
> ----
> This behavior is not related to the bean discovery mode defined in the "beans.xml" of the deployment. Actually, the code responsible for handling bean discovery in deployments and in their dependency is clearly separated. It seems that {{ExternalBeanArchiveProcessor}} is responsible for bean discovery in dependencies, and this class completely ignores the bean discovery mode defined in the {{bean.xml}} and always populate the archive with every single discovered class:
> {code}
> final BeansXml beansXml = parseBeansXml(url, parser, deploymentUnit);
> final UrlScanner urlScanner = new UrlScanner();
> final List<String> discoveredClasses = new ArrayList<String>();
> if (!urlScanner.handleBeansXml(url, discoveredClasses)) {
> continue;
> }
> discoveredClasses.removeAll(componentClassNames);
> /*
> * Below, the archive is populated with every discovered class,
> * irrespective of beansXML.getBeanDiscoveryMode()
> */
> final BeanDeploymentArchiveImpl bda = new BeanDeploymentArchiveImpl(new HashSet<String>(discoveredClasses), beansXml, dependency, beanArchiveIdPrefix + url.toExternalForm(), BeanArchiveType.EXTERNAL);
> {code}
> There seems to be hard-coded exceptions for {{jsf-impl-2.2}} and {{resteasy-cdi}}, so I suspect this problem has been noticed before, but I couldn't find any open ticket.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9509) Default SFSB Lifecycle methods transaction attribute causing warnings
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-9509:
----------------------------------
Summary: Default SFSB Lifecycle methods transaction attribute causing warnings
Key: WFLY-9509
URL: https://issues.jboss.org/browse/WFLY-9509
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 11.0.0.Final
Reporter: Brad Maxwell
EJB 2 deployment that does not specify transaction attribute for lifecycle methods such as: ejbActivate, ejbRemove, ejbPassivate are logging this warning.
JBAS014279: Invalid transaction attribute type REQUIRED on SFSB lifecyle method Method ejbRemove(), valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-7957) Redirecting to external ports such as 443 is not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7957?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7957.
----------------------------------
Resolution: Rejected
> Redirecting to external ports such as 443 is not working
> --------------------------------------------------------
>
> Key: WFLY-7957
> URL: https://issues.jboss.org/browse/WFLY-7957
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 10.1.0.Final
> Environment: Windows Server 2012 R2 Standard, 64bit
> Reporter: Bhaskara Undi
> Assignee: Stuart Douglas
>
> 2017-01-24 10:57:17,812 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60).........
> ------------------
> <server-identities>
> <ssl>
> <keystore path="edustgkeystore.jks" relative-to="jboss.server.config.dir" keystore-password="pass" alias="server"/>
> </ssl>
> </server-identities>
> -----------------------------
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <ajp-listener name="listen-ajp" socket-binding="ajp"/>
> <http-listener name="default" socket-binding="http" redirect-socket="https-ext" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" security-realm="SSLRealm" enable-http2="true"/>
> -------------------------------
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9461) Occasional 404 response during graceful shutdown
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9461?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-9461:
---------------------------------
Labels: fixed_upstream (was: )
> Occasional 404 response during graceful shutdown
> ------------------------------------------------
>
> Key: WFLY-9461
> URL: https://issues.jboss.org/browse/WFLY-9461
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 12.0.0.Alpha1
>
>
> I have simple war app with simple servlet doing:
> {noformat}
> resp.setContentType("text/plain");
> String servletId = (String) req.getServletContext().getAttribute("servletId");
> System.out.println("requestedSessionId: " + req.getRequestedSessionId() + ", queryString: " + req.getQueryString());
> HttpSession session = req.getSession();
> Long counter = (Long) session.getAttribute("counter");
> if (counter == null) {
> counter = 0L;
> }
> counter++;
> session.setAttribute("counter", counter);
> PrintWriter writer = resp.getWriter();
> writer.println(servletId + " " + counter);
> writer.close();
> {noformat}
> There are running 256 clients (apache http client) hitting this servlet. When I manually introduce graceful shutdown (timeout 5s) I can occasionally see some 404 (0-10) responses (instead of 503). This response is not listed in the access log. The server log looks like:
> {noformat}2017-09-13 11:54:21,070 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0211: Suspending server with 5000 ms timeout.
> 2017-09-13 11:54:21,072 INFO [org.jboss.as.ejb3] (management-handler-thread - 3) WFLYEJB0493: EJB subsystem suspension complete
> 2017-09-13 11:54:21,074 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> 2017-09-13 11:54:21,104 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 2) WFLYUT0022: Unregistered web context: '/' from server 'default-server'
> 2017-09-13 11:54:21,121 TRACE [io.undertow.request] (default I/O-1) Opened connection with /127.0.0.1:44328
> 2017-09-13 11:54:21,121 TRACE [io.undertow.request] (default I/O-5) Opened connection with /127.0.0.1:44324
> 2017-09-13 11:54:21,122 DEBUG [io.undertow.request] (default I/O-1) Matched default handler path /Counter
> 2017-09-13 11:54:21,122 DEBUG [io.undertow.request] (default I/O-5) Matched default handler path /Counter
> 2017-09-13 11:54:21,132 TRACE [io.undertow.session] (ServerService Thread Pool -- 2) Bumping timeout for session KykwjKuYLFildYvXtaqCr6CHPhlQcFvq715M6CMU to 1505298261132
> ....
> 2017-09-13 11:54:21,205 TRACE [io.undertow.session] (ServerService Thread Pool -- 2) Bumping timeout for session KA4RbDMrYmi28CebEz2NzPe7sqAX35OhU95U9jvC to 1505298261205
> 2017-09-13 11:54:21,205 TRACE [io.undertow.session] (ServerService Thread Pool -- 2) Removing session attribute counter for session KA4RbDMrYmi28CebEz2NzPe7sqAX35OhU95U9jvC
> 2017-09-13 11:54:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2017-09-13 11:54:21,214 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host default-host stopping
> 2017-09-13 11:54:21,217 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2017-09-13 11:54:21,233 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 23) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2017-09-13 11:54:21,253 TRACE [io.undertow.request] (default I/O-5) Opened connection with /127.0.0.1:44332
> 2017-09-13 11:54:21,253 TRACE [io.undertow.server.handlers.ResponseCodeHandler] (default I/O-5) Setting response code 404 for exchange HttpServerExchange{ GET /Counter request {Connection=[Keep-Alive], Accept-Encoding=[gzip,deflate], User-Agent=[Apache-HttpClient/4.3.6.redhat-1 (java 1.5)], Host=[localhost:8080]} response {}}
> 2017-09-13 11:54:21,253 TRACE [io.undertow.server.HttpServerExchange] (default I/O-5) Starting to write response for HttpServerExchange{ GET /Counter request {Connection=[Keep-Alive], Accept-Encoding=[gzip,deflate], User-Agent=[Apache-HttpClient/4.3.6.redhat-1 (java 1.5)], Host=[localhost:8080]} response {Connection=[keep-alive], Content-Length=[74], Content-Type=[text/html], Date=[Wed, 13 Sep 2017 09:54:21 GMT]}}
> 2017-09-13 11:54:21,262 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending
> 2017-09-13 11:54:21,262 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTPS listener https suspending
> 2017-09-13 11:54:21,263 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to 127.0.0.1:8443
> 2017-09-13 11:54:21,263 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2017-09-13 11:54:21,264 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.18.Final-redhat-1 stopping
> 2017-09-13 11:54:21,286 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment ROOT.war (runtime-name: ROOT.war) in 191ms
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-9461) Occasional 404 response during graceful shutdown
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9461?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-9461:
---------------------------------
Labels: (was: fixed_upstream)
> Occasional 404 response during graceful shutdown
> ------------------------------------------------
>
> Key: WFLY-9461
> URL: https://issues.jboss.org/browse/WFLY-9461
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 12.0.0.Alpha1
>
>
> I have simple war app with simple servlet doing:
> {noformat}
> resp.setContentType("text/plain");
> String servletId = (String) req.getServletContext().getAttribute("servletId");
> System.out.println("requestedSessionId: " + req.getRequestedSessionId() + ", queryString: " + req.getQueryString());
> HttpSession session = req.getSession();
> Long counter = (Long) session.getAttribute("counter");
> if (counter == null) {
> counter = 0L;
> }
> counter++;
> session.setAttribute("counter", counter);
> PrintWriter writer = resp.getWriter();
> writer.println(servletId + " " + counter);
> writer.close();
> {noformat}
> There are running 256 clients (apache http client) hitting this servlet. When I manually introduce graceful shutdown (timeout 5s) I can occasionally see some 404 (0-10) responses (instead of 503). This response is not listed in the access log. The server log looks like:
> {noformat}2017-09-13 11:54:21,070 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0211: Suspending server with 5000 ms timeout.
> 2017-09-13 11:54:21,072 INFO [org.jboss.as.ejb3] (management-handler-thread - 3) WFLYEJB0493: EJB subsystem suspension complete
> 2017-09-13 11:54:21,074 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> 2017-09-13 11:54:21,104 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 2) WFLYUT0022: Unregistered web context: '/' from server 'default-server'
> 2017-09-13 11:54:21,121 TRACE [io.undertow.request] (default I/O-1) Opened connection with /127.0.0.1:44328
> 2017-09-13 11:54:21,121 TRACE [io.undertow.request] (default I/O-5) Opened connection with /127.0.0.1:44324
> 2017-09-13 11:54:21,122 DEBUG [io.undertow.request] (default I/O-1) Matched default handler path /Counter
> 2017-09-13 11:54:21,122 DEBUG [io.undertow.request] (default I/O-5) Matched default handler path /Counter
> 2017-09-13 11:54:21,132 TRACE [io.undertow.session] (ServerService Thread Pool -- 2) Bumping timeout for session KykwjKuYLFildYvXtaqCr6CHPhlQcFvq715M6CMU to 1505298261132
> ....
> 2017-09-13 11:54:21,205 TRACE [io.undertow.session] (ServerService Thread Pool -- 2) Bumping timeout for session KA4RbDMrYmi28CebEz2NzPe7sqAX35OhU95U9jvC to 1505298261205
> 2017-09-13 11:54:21,205 TRACE [io.undertow.session] (ServerService Thread Pool -- 2) Removing session attribute counter for session KA4RbDMrYmi28CebEz2NzPe7sqAX35OhU95U9jvC
> 2017-09-13 11:54:21,211 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2017-09-13 11:54:21,214 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0019: Host default-host stopping
> 2017-09-13 11:54:21,217 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2017-09-13 11:54:21,233 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 23) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2017-09-13 11:54:21,253 TRACE [io.undertow.request] (default I/O-5) Opened connection with /127.0.0.1:44332
> 2017-09-13 11:54:21,253 TRACE [io.undertow.server.handlers.ResponseCodeHandler] (default I/O-5) Setting response code 404 for exchange HttpServerExchange{ GET /Counter request {Connection=[Keep-Alive], Accept-Encoding=[gzip,deflate], User-Agent=[Apache-HttpClient/4.3.6.redhat-1 (java 1.5)], Host=[localhost:8080]} response {}}
> 2017-09-13 11:54:21,253 TRACE [io.undertow.server.HttpServerExchange] (default I/O-5) Starting to write response for HttpServerExchange{ GET /Counter request {Connection=[Keep-Alive], Accept-Encoding=[gzip,deflate], User-Agent=[Apache-HttpClient/4.3.6.redhat-1 (java 1.5)], Host=[localhost:8080]} response {Connection=[keep-alive], Content-Length=[74], Content-Type=[text/html], Date=[Wed, 13 Sep 2017 09:54:21 GMT]}}
> 2017-09-13 11:54:21,262 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending
> 2017-09-13 11:54:21,262 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTPS listener https suspending
> 2017-09-13 11:54:21,263 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to 127.0.0.1:8443
> 2017-09-13 11:54:21,263 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2017-09-13 11:54:21,264 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.4.18.Final-redhat-1 stopping
> 2017-09-13 11:54:21,286 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment ROOT.war (runtime-name: ROOT.war) in 191ms
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month