[JBoss JIRA] (WFCORE-3387) MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3387?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3387:
-----------------------------------------------
Hi,
I am sorry that I could not provide a sample application any time sooner.
I have now uploaded a very simple sample application to the following address.
https://github.com/99sono/wildfly-jmx-query-appdeploymentbean
This is an application that should be trivial to deploy since it has no persistence.xml.
What the application shows, when we deploy it is that that our class:
jmx.RegisterAppDeploymentStartupEjb
Is not successful in getting any results during the @Startup phase for deployed applications or ongoing deployments.
However, the class is successful in registering a listener.
Then there is a second phenomena that only happens on this tiny application, but not on the big application where we try to put this post deployment notificaiton.
That is that when we deploy the first on this small application the mechanism to subscribe to the "deployed" event is working perfectly, although we had to hard code the name of the managed bean.
But if on eclipse we remove the WAR file and add it a second time, the NotficationListner will break apart when it gets notified due "ApplicationContext" not being active.
This can be seen in the REAME.md of the URL i sent above.
I can understand that registerning as JMX listner an @ApplicationScoped bean is kind of a dirty thing to do.
But it should either always fail or always work.
And to be quite honest, CDI beans are just too convenient not to use.
In the case of our applicaton the Listener will send out a JMS message to topic notifying that the application is deployed.
In this case, the application scoped bean just needs log a message sayin:
jmx.WildflyAppDeploymentMbeanListener
{panel}
LOGGER.info("\n\n\n IMPORTANT NOTIFICATION: {} . WE KNOW THAT THE APPLICATION {} IS DEPLOYED. "
+ "\n\n But it was necessary to hard code the managed bean name "
+ "\n\n We do not want to be hard coding WAR names to do our registration."
+ "\n\n Ideally we want to query and find the app that is suitable. ", notification, warName);
{panel}
Finally, the third and final problem we detect, is that if on eclipse on a deployed appliation we click "restart", we shall get no notification that the application is deployed.
Many thanks for considering this issue.
I await your feedback.
If you know of a better way to detect that an application has just been deployed that is not the @Startup ejb phase (because at this point the deployment is not finished) I would welcome the information.
Right now we have this managed bean approach working Wildfly and another application server. But on wildfly we have these phenomenas explained above.
Kindest regards.
> 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)
8 years, 8 months
[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2232:
---------------------------
Fix Version/s: 4.0.9
> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
> Key: JGRP-2232
> URL: https://issues.jboss.org/browse/JGRP-2232
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.7
> Environment: Spring Boot / Boxfuse / AWS
> Reporter: Jesper Blomquist
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.9
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2232:
--------------------------------
Try reducing {{logical_addr_cache_max_size}} (default: 2000).
> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
> Key: JGRP-2232
> URL: https://issues.jboss.org/browse/JGRP-2232
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.7
> Environment: Spring Boot / Boxfuse / AWS
> Reporter: Jesper Blomquist
> Assignee: Bela Ban
> Priority: Minor
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (ELY-1430) WARN logged during server shutdown when Elytron JACC is set
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1430?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev moved WFCORE-3390 to ELY-1430:
--------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1430 (was: WFCORE-3390)
Component/s: (was: Security)
Affects Version/s: 1.2.0.Beta8
(was: 3.0.9.Final)
> WARN logged during server shutdown when Elytron JACC is set
> -----------------------------------------------------------
>
> Key: ELY-1430
> URL: https://issues.jboss.org/browse/ELY-1430
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.2.0.Beta8
> Reporter: Ondrej Kotek
> Assignee: Ilia Vassilev
> Priority: Critical
>
> When Elytron JACC policy resource is defined, there is WARN logged during server shutdown:
> {{WARN [org.wildfly.security] (MSC service thread 1-8) ELY08509: Calling any of the Policy.getPermissions() methods is not supported; please see the Java Authorization Contract for Containers (JACC) specification (section "1.4 Requirements", item 1) and the Java SE API specification for the Policy.getPermissions() methods for more information. Instead, use the Policy.implies() method for authorization checking.}}
> This is suspicious behaviour. Customers that monitor logs for warnings have to deal with this. Setting Critical.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9497) Add clustering externalizers for common JDK abstract classes
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9497?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9497:
-------------------------------
Description:
A number of JDK objects are common in a web session, where the implementation class is private or unimportant. Our current ObjectTable implementation chooses its externalizer based on the implementation class, so some modifications are required to accept externalizers whose target class is abstract.
e.g. TimeZone, ZoneId, Calendar
was:e.g. TimeZone, ZoneId, Calendar
> Add clustering externalizers for common JDK abstract classes
> ------------------------------------------------------------
>
> Key: WFLY-9497
> URL: https://issues.jboss.org/browse/WFLY-9497
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 12.0.0.Alpha1
>
>
> A number of JDK objects are common in a web session, where the implementation class is private or unimportant. Our current ObjectTable implementation chooses its externalizer based on the implementation class, so some modifications are required to accept externalizers whose target class is abstract.
> e.g. TimeZone, ZoneId, Calendar
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3397) Integrate improved thread pool implementation
by David Lloyd (JIRA)
David Lloyd created WFCORE-3397:
-----------------------------------
Summary: Integrate improved thread pool implementation
Key: WFCORE-3397
URL: https://issues.jboss.org/browse/WFCORE-3397
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Domain Management, IO, Server, Test Suite
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 4.0.0.Alpha3
Introduce new thread pool implementation with separate core/max size and configurable parameters, and reuse-idle-thread behavior.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-5332:
---------------------------------
Assignee: David Lloyd (was: Panagiotis Sotiropoulos)
> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5332
> URL: https://issues.jboss.org/browse/WFLY-5332
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: David Lloyd
> Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new
> thread [up until max-threads]."
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed
by Jesper Blomquist (JIRA)
Jesper Blomquist created JGRP-2232:
--------------------------------------
Summary: Using NATIVE_S3_PING old members doesn't seem to get removed
Key: JGRP-2232
URL: https://issues.jboss.org/browse/JGRP-2232
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.7
Environment: Spring Boot / Boxfuse / AWS
Reporter: Jesper Blomquist
Assignee: Bela Ban
Priority: Minor
According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
967 elements:
i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months