[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one
by Dennis Reed (JIRA)
Dennis Reed created JGRP-2131:
---------------------------------
Summary: UNICAST3 drops all messages until it receives the first one
Key: JGRP-2131
URL: https://issues.jboss.org/browse/JGRP-2131
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.10
Reporter: Dennis Reed
Assignee: Bela Ban
UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet.
This causes UNICAST3.handleDataReceived to drop the message.
When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1362) accumulate and over window:time usage will stuck drools for a while (from minutes to hours according to number of facts)
by Ertugrul Akbas (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1362?page=com.atlassian.jira.plugi... ]
Ertugrul Akbas updated DROOLS-1362:
-----------------------------------
Attachment: Droolslog.zip
> accumulate and over window:time usage will stuck drools for a while (from minutes to hours according to number of facts)
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1362
> URL: https://issues.jboss.org/browse/DROOLS-1362
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Ertugrul Akbas
> Assignee: Mario Fusco
> Attachments: Droolslog.zip
>
>
> We are testing a simple rule. The rule is:
> import com.anet.correlation.*;
> import java.util.*;
> import com.anet.ntLog.collector.*;
> import com.anet.alarm.*;
> import com.anet.util.*;
> import com.anet.correlation.operators.*;
> import com.anet.correlation.utils.*;
> declare EPSObject
> @role(event)
>
> end
> rule "test"
> when
> Number( ) from accumulate(
> generalcorrelationobject1:EPSObject(name=='ert', $temp :avg_snmptrapeps) over window:time( 3m ),
> average( $temp ) )
> then
> end
> we are inserting facts continuously and after 3 minutes - the time which is given as "over window:time( 3m )" -
> drools stuck and then after minutes , starts to conitinue.
> Not: When we test with "over window:time( 30m )" stuck 30 minutes later or When we test with "over window:time( 10m )" stuck 10 minutes later
> Any comment?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 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:
---------------------------------------
Just for an example here is a simple interface and the generated implementation.
{code:java|title=ValidLogger.java}
@MessageLogger(projectCode = AbstractLoggerTest.PROJECT_CODE)
public interface ValidLogger {
ValidLogger LOGGER = Logger.getMessageLogger(ValidLogger.class, AbstractLoggerTest.CATEGORY);
/**
* Logs an error message indicating there was a processing error.
*
* @param cause the cause of the error.
* @param moduleName the module that caused the error.
*/
@LogMessage(level = Level.ERROR)
@Message(id = 201, value = "Processing error in module '%s'")
void processingError(@Cause Throwable cause, String moduleName);
/**
* Logs an error message indicating a processing error.
*
* @param on the object the error occurred on
* @param message the error message
*/
@LogMessage(level = Level.ERROR)
@Message(id = 203, value = "Processing error on '%s' with error '%s'")
void processingError(Object on, String message);
}
{code}
{code:java|title=ValidLogger_$logger.java}
@Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-11-15T13:34:22-0800")
public class ValidLogger_$logger implements ValidLogger, Serializable {
private static final long serialVersionUID = 1L;
private static final String FQCN = ValidLogger_$logger.class.getName();
public ValidLogger_$logger(final Logger log) {
this.log = log;
}
protected final Logger log;
@Override
public final void processingError(final Throwable cause, final String moduleName) {
log.logf(FQCN, ERROR, cause, processingError1$str(), moduleName);
}
private static final String processingError1 = "LOGL000201: Processing error in module '%s'";
protected String processingError1$str() {
return processingError1;
}
@Override
public final void processingError(final Object on, final String message) {
log.logf(FQCN, ERROR, null, processingError2$str(), on, message);
}
private static final String processingError2 = "LOGL000203: Processing error on '%s' with error '%s'";
protected String processingError2$str() {
return processingError2;
}
}
{code}
> 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.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, 8 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:
---------------------------------------
All logging methods use the delegating {{org.jboss.logging.Logger}} without formatting anything. The formatting of the message is done in the logger implementation so the level can be checked before the formatting is done. The tooling could generate the same checks I suppose and do the formatting. At this point though we let JBoss Logging handle all the formatting of log messages.
> 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.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, 8 months
[JBoss JIRA] (JBLOGGING-125) Add log methods that accept a Locale for formatting
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-125?page=com.atlassian.jira.plu... ]
James Perkins updated JBLOGGING-125:
------------------------------------
Description: When formatting log messages with {{String.format()}} should allow for a {{Locale}} to be passed in and as a parameter defaulting to {{Locale.getDefault()}}. (was: When formatting log messages with {{String.format()}} should allow for a {{Locale}} to be passed in and as a parameter defaulting to {{Locale.ROOT}}.)
> Add log methods that accept a Locale for formatting
> ---------------------------------------------------
>
> Key: JBLOGGING-125
> URL: https://issues.jboss.org/browse/JBLOGGING-125
> Project: JBoss Logging
> Issue Type: Enhancement
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> When formatting log messages with {{String.format()}} should allow for a {{Locale}} to be passed in and as a parameter defaulting to {{Locale.getDefault()}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
David Lloyd commented on LOGTOOL-116:
-------------------------------------
Does the log tool need to support it though? After all it's generally always formatting the string in the implementation class, right?
> 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.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, 8 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/15/16 4:15 PM:
-----------------------------------------------------------------
Right yes. What I meant was that the {{org.jboss.logging.Logger.logf()}} should have a {{Locale}} parameter. For some implementations the {{String.format()}} is used directly and others, like the JBoss Log Manager, we might want to pass the locale to the backing logger. So it would just be something like
{code:java}
log.logf(getLoggingLocale(), FQCN, INFO, cause, myMessage$str(), params);
{code}
was (Author: jamezp):
Right yes. What I meant was that the `org.jboss.logging.Logger.logf()` should have a `Locale` parameter. For some implementations the `String.format()` is used directly and others, like the JBoss Log Manager, we might want to pass the locale to the backing logger. So it would just be something like
{code:java}
log.logf(getLoggingLocale(), FQCN, INFO, cause, myMessage$str(), params);
{code}
> 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.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, 8 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:
---------------------------------------
Right yes. What I meant was that the `org.jboss.logging.Logger.logf()` should have a `Locale` parameter. For some implementations the `String.format()` is used directly and others, like the JBoss Log Manager, we might want to pass the locale to the backing logger. So it would just be something like
{code:java}
log.logf(getLoggingLocale(), FQCN, INFO, cause, myMessage$str(), params);
{code}
> 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.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, 8 months