[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6561:
--------------------------------------
That message has nothing to do with this JIRA, it happens when a timer task takes a long time and the next execution starts before the current one is finished.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-120) Locale is not used in the actual string format for loggers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-120?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-120:
----------------------------------
Fix Version/s: 2.1.0.Alpha2
(was: 2.1.0.Alpha1)
> Locale is not used in the actual string format for loggers
> ----------------------------------------------------------
>
> Key: LOGTOOL-120
> URL: https://issues.jboss.org/browse/LOGTOOL-120
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.1.0.Alpha2
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-122) Add option to always add positional parameters to generated translation files
by James Perkins (JIRA)
James Perkins created LOGTOOL-122:
-------------------------------------
Summary: Add option to always add positional parameters to generated translation files
Key: LOGTOOL-122
URL: https://issues.jboss.org/browse/LOGTOOL-122
Project: Log Tool
Issue Type: Enhancement
Reporter: James Perkins
Priority: Minor
Translated languages may reorder text resulting in parameters requiring to be in a different order. If the translator does not know the positional format, i.e. {{%1$s}}, the message parameters may be inserted in the incorrect order.
There should be an option to allow parameters to be generated with the positional properties. A message such as {{Parameter %s has an invalid value %s}} should be printed to the properties file as {{Parameter %1$s has an invalid value %2$s}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-121) Validation does not handle positional formatting correctly
by James Perkins (JIRA)
James Perkins created LOGTOOL-121:
-------------------------------------
Summary: Validation does not handle positional formatting correctly
Key: LOGTOOL-121
URL: https://issues.jboss.org/browse/LOGTOOL-121
Project: Log Tool
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
Given a format pattern of {{%2$s text %n%1$s}} the validation will fail because both the {{%n}} and {{%1$s}} are counted as "1" for their index. Formats that don't require parameters don't need a parameter index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-120) Locale is not used in the actual string format for loggers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-120?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-120:
---------------------------------------
Note this was cloned and this JIRA is for supporting passing the locale to loggers. Message bundles have already been implemented as part of LOGTOOL-116.
> Locale is not used in the actual string format for loggers
> ----------------------------------------------------------
>
> Key: LOGTOOL-120
> URL: https://issues.jboss.org/browse/LOGTOOL-120
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-120) Locale is not used in the actual string format for loggers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-120?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-120:
----------------------------------
Summary: Locale is not used in the actual string format for loggers (was: Locale is not used in the actual string format.)
> Locale is not used in the actual string format for loggers
> ----------------------------------------------------------
>
> Key: LOGTOOL-120
> URL: https://issues.jboss.org/browse/LOGTOOL-120
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-120) Locale is not used in the actual string format for loggers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-120?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-120:
----------------------------------
Fix Version/s: (was: 2.0.2.Final)
> Locale is not used in the actual string format for loggers
> ----------------------------------------------------------
>
> Key: LOGTOOL-120
> URL: https://issues.jboss.org/browse/LOGTOOL-120
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins edited comment on LOGTOOL-116 at 11/18/16 6:57 PM:
-----------------------------------------------------------------
Prematurely closed this. This is partially done. Bundle messages now use a {{getLoggingLocale()}} method. Loggers still need to be implemented, but it relies on changes in JBoss Logging and JBoss Log Manager to work as expected.
This JIRA will include the changes only for message bundles. LOGTOOL-120 was created to support loggers.
was (Author: jamezp):
Prematurely closed this. This is partially done. Bundle messages now use a {{getLoggingLocale()}} method. Loggers still need to be implemented, but it relies on changes in JBoss Logging and JBoss Log Manager to work as expected.
> Locale is not used in the actual string format.
> -----------------------------------------------
>
> Key: LOGTOOL-116
> URL: https://issues.jboss.org/browse/LOGTOOL-116
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.0.2.Final, 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-116:
---------------------------------------
Prematurely closed this. This is partially done. Bundle messages now use a {{getLoggingLocale()}} method. Loggers still need to be implemented, but it relies on changes in JBoss Logging and JBoss Log Manager to work as expected.
> Locale is not used in the actual string format.
> -----------------------------------------------
>
> Key: LOGTOOL-116
> URL: https://issues.jboss.org/browse/LOGTOOL-116
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.0.2.Final, 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months