January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB messages and message batches

by Bela Ban (JIRA)

Bela Ban created JGRP-1767: ------------------------------ Summary: UNICAST3: processing of OOB messages and message batches Key: JGRP-1767 URL: https://issues.jboss.org/browse/JGRP-1767 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.5 Currently, when OOB message batches are received, the following happens: * All messages from the batch are added to the table * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread). * The batch is passed up * Then we try to remove as many messages from the table as possible and pass them up (as a batch again) ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient: * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet ** Batch *** we only add those messages from list L to table T if they haven't yet been added *** Messages from L which couldn't be added to T are removed from L *** All messages from L are added to a new batch and that batch is then passed up (delivered) ** Single message *** If the message was added successfuly, we deliver it, else we drop it * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter) * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2618?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2618: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1049796|https://bugzilla.redhat.com/show_bug.cgi?id=1049796] from NEW to POST > Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2618 > URL: https://issues.jboss.org/browse/WFLY-2618 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI... > The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-89) LogContext's root logger is not created with a strong child hash map when strong=true

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on LOGMGR-89: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1031221|https://bugzilla.redhat.com/show_bug.cgi?id=1031221] from NEW to MODIFIED > LogContext's root logger is not created with a strong child hash map when strong=true > ------------------------------------------------------------------------------------- > > Key: LOGMGR-89 > URL: https://issues.jboss.org/browse/LOGMGR-89 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit) > Reporter: Kyle Lape > Assignee: David Lloyd > Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1 > > > When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost. > Given this configuration > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> > <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true"> > <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender"> > <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/> > <param name="MaxFileSize" value="2MB"/> > <param name="MaxBackupIndex" value="5"/> > <param name="Append" value="true"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/> > </layout> > </appender> > <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender"> > <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/> > <param name="MaxFileSize" value="2MB"/> > <param name="MaxBackupIndex" value="5"/> > <param name="Append" value="true"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/> > </layout> > </appender> > <logger name="com.redhat" additivity="false"> > <level value="TRACE"/> > <appender-ref ref="SAMPLE_APP_MDB"/> > </logger> > <root> > <priority value="TRACE"/> > <appender-ref ref="SAMPLE_APP"/> > </root> > </log4j:configuration> > {code} > Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used. One message like this is also printed to the log: > {noformat} > 11:33:00,110 INFO [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB]. > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-281) Inconsistent use of genStringAsCharArray.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-281: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from NEW to POST > Inconsistent use of genStringAsCharArray. > ----------------------------------------- > > Key: JBWEB-281 > URL: https://issues.jboss.org/browse/JBWEB-281 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.2.1.GA > Environment: All environments. > Reporter: Jeremy Whiting > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled. > This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache. > Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-282) Lack of synchronization in org.apache.catalina.security.SecurityUtil

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-282: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from NEW to POST > Lack of synchronization in org.apache.catalina.security.SecurityUtil > -------------------------------------------------------------------- > > Key: JBWEB-282 > URL: https://issues.jboss.org/browse/JBWEB-282 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA > Environment: -JBoss EAP 6.1.1 > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50138 > objectCache now needs to be a ConcurrentHashMap given our multithreaded starts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-281) Inconsistent use of genStringAsCharArray.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-281: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from NEW to POST > Inconsistent use of genStringAsCharArray. > ----------------------------------------- > > Key: JBWEB-281 > URL: https://issues.jboss.org/browse/JBWEB-281 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.2.1.GA > Environment: All environments. > Reporter: Jeremy Whiting > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled. > This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache. > Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-282) Lack of synchronization in org.apache.catalina.security.SecurityUtil

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-282: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from NEW to POST > Lack of synchronization in org.apache.catalina.security.SecurityUtil > -------------------------------------------------------------------- > > Key: JBWEB-282 > URL: https://issues.jboss.org/browse/JBWEB-282 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA > Environment: -JBoss EAP 6.1.1 > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Fix For: JBossWeb-7.3.0.GA > > > The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50138 > objectCache now needs to be a ConcurrentHashMap given our multithreaded starts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-394) java.lang.RuntimeException: cannot invoke getter

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-394?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-394: --------------------------------------- Are you sure that responseData is 1) always not null and 2) always an instance of EnergyUsage? You'll also have to make sure that none of the intermediate getters returns null. > java.lang.RuntimeException: cannot invoke getter > ------------------------------------------------ > > Key: DROOLS-394 > URL: https://issues.jboss.org/browse/DROOLS-394 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: leonardo lizana > Assignee: Mark Proctor > > we are using drools 5.4.final. and below is the rule > rule "EnergyUsage data not empty" > dialect "java" > salience 100 > no-loop > when > $httpResponse : HttpResponse( > (((EnergyUsage)responseData).energyUsageDetail.billingGroup!=null && ((EnergyUsage)responseData).energyUsageDetail.billingGroup!=0) || > ((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()>0 || > ((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()>0 || > ((EnergyUsage)responseData).energyUsageDetail.servicePoint!=null || > ((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() > 0 > ); > > > then > System.out.println("[EnergyUsage data not empty] rule has been fired..."); > $httpResponse.setStatusCode(EisConstants.STATUS_OK); > $httpResponse.setErrorMessage(""); > end > rule "EnergyUsage data empty" > dialect "java" > no-loop > when > $httpResponse : HttpResponse( > (((EnergyUsage)responseData).energyUsageDetail.billingGroup==null || ((EnergyUsage)responseData).energyUsageDetail.billingGroup==0) && > ((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()==0 && > ((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()==0 && > ((EnergyUsage)responseData).energyUsageDetail.servicePoint==null && > ((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() == 0 > ); > > > then > System.out.println("[EnergyUsage data empty] rule has been fired..."); > $httpResponse.setStatusCode(EisConstants.STATUS_OK); > $httpResponse.setErrorMessage("Data Screen Scrapping is empty for this account"); > end > Here is log error: > ------------------------- > java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace) > at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74) > at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41) > at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107) > at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34) > at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34) > at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34) > at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34) > at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85) > at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123) > at org.mvel2.MVEL.executeExpression(MVEL.java:930) > at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70) > at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124) > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137) > at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) > at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:337) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269) > at com.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309) > at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110) > at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) > at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) > at $Proxy161.ruleCompliance(Unknown Source) > at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from NEW to POST > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from NEW to POST > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2014