November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1717: -------------------------------- Note that batching does make sense for regular messages: since all messages in a batch are from the same sender, we'd have to deliver them in turn anyway. Therefore, delivering them as a batch is more efficient. > Bundling reduces performance in scenario mimicking Inifinispan > -------------------------------------------------------------- > > Key: JGRP-1717 > URL: https://issues.jboss.org/browse/JGRP-1717 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.5 > > Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml > > > In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance. > See attached configurations and results. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1717 at 11/7/13 10:04 AM: ---------------------------------------------------------- Note that batching does make sense for regular messages: since all messages in a batch are from the same sender, we'd have to deliver them in turn anyway (to preserve FIFO order). Therefore, delivering them as a batch is more efficient. was (Author: belaban): Note that batching does make sense for regular messages: since all messages in a batch are from the same sender, we'd have to deliver them in turn anyway. Therefore, delivering them as a batch is more efficient. > Bundling reduces performance in scenario mimicking Inifinispan > -------------------------------------------------------------- > > Key: JGRP-1717 > URL: https://issues.jboss.org/browse/JGRP-1717 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.5 > > Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml > > > In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance. > See attached configurations and results. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1717: -------------------------------- I think the underlying problem is that bundled *OOB messages* will get delivered as message *batches* at the receiver(s). This means that if we have a batch of 5 OOB RPCs [1,2,3,4,5], then RPC #1 will get invoked, then RPC #2 etc, *even if these RPCs are all tagged as OOB*. RPC #5 for example will be delayed by the cummulative delays of all RPCs ahead of it. So while message batching increases throughput, it also increases latency, which decreases performance of synchronous RPCs. Note that the RPC responses are also going to be delivered as a batch. Therefore, currently message batching and sync OOB RPCs only makes sense if the receivers use the Async Invocation API and and internal thread pool. If this is not the case, sync OOB RPCs should be marked with a {{DONT_BUNDLE}} flag. > Bundling reduces performance in scenario mimicking Inifinispan > -------------------------------------------------------------- > > Key: JGRP-1717 > URL: https://issues.jboss.org/browse/JGRP-1717 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.5 > > Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml > > > In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance. > See attached configurations and results. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-5970) RichFaces Showcase portlet is unable to switch skins

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5970?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5970: ---------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 877560|https://bugzilla.redhat.com/show_bug.cgi?id=877560] from VERIFIED to CLOSED > RichFaces Showcase portlet is unable to switch skins > ---------------------------------------------------- > > Key: AS7-5970 > URL: https://issues.jboss.org/browse/AS7-5970 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ken Finnigan > Assignee: Stan Silvert > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > The following exception is thrown when the user changes skins for the second time immediately after changing the skin for the first time: > {noformat} > Caused by: javax.faces.FacesException: Cannot remove the same component twice: pbG9dea276d_2dee9e_2d4150_2dad91_2d22255b5a57d2_j_id1:j_idt444 > at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:489) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at com.sun.faces.context.StateContext$AddRemoveListener.handleRemove(StateContext.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:334) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1] > {noformat} > This error manifests due to the Portlet Bridge needing to retain the UIViewRoot from JSF between Portlet Requests, which causes the list of component tree actions, ie. adding and removing, to be retained making JSF think that it's trying to remove a component that was actually removed in a previous request. > This has been raised as http://java.net/jira/browse/JAVASERVERFACES-2609, but wanted to raise this as a tracker so that when that fix is available it can be incorporated. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2371) SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2371: ----------------------------------------------- Pavel Jelinek <pjelinek(a)redhat.com> made a comment on [bug 1020339|https://bugzilla.redhat.com/show_bug.cgi?id=1020339] Fixed in 6.2.0.ER7. > SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size" > ------------------------------------------------------------------------------------------ > > Key: WFLY-2371 > URL: https://issues.jboss.org/browse/WFLY-2371 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Petr Kremensky > Assignee: Petr Kremensky > > The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with: > java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1 > Link to job: > https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-t... -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2371) SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2371: ----------------------------------------------- Pavel Jelinek <pjelinek(a)redhat.com> changed the Status of [bug 1020339|https://bugzilla.redhat.com/show_bug.cgi?id=1020339] from ON_QA to VERIFIED > SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size" > ------------------------------------------------------------------------------------------ > > Key: WFLY-2371 > URL: https://issues.jboss.org/browse/WFLY-2371 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Petr Kremensky > Assignee: Petr Kremensky > > The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with: > java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1 > Link to job: > https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-t... -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin... ] Kris Verlaenen resolved DROOLS-326. ----------------------------------- Fix Version/s: 6.0.1.Final Resolution: Done > Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions > ------------------------------------------------------------------------------------------- > > Key: DROOLS-326 > URL: https://issues.jboss.org/browse/DROOLS-326 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR5 > Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45 > Reporter: Duncan Doyle > Assignee: Mark Proctor > Labels: conditional, consequence, eclipse, named, plugin, rete, tree, view > Fix For: 6.0.1.Final > > > See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue > The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error: > Rete Tree Build Error! > Reason: > org.drools.core.RuntimeDroolsException: > java.lang.reflect.InvocationTargetException : [Rete(0)] > And the Rete Tree is not displayed. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin... ] Kris Verlaenen reassigned DROOLS-326: ------------------------------------- Assignee: Kris Verlaenen (was: Mark Proctor) > Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions > ------------------------------------------------------------------------------------------- > > Key: DROOLS-326 > URL: https://issues.jboss.org/browse/DROOLS-326 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR5 > Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45 > Reporter: Duncan Doyle > Assignee: Kris Verlaenen > Labels: conditional, consequence, eclipse, named, plugin, rete, tree, view > Fix For: 6.0.1.Final > > > See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue > The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error: > Rete Tree Build Error! > Reason: > org.drools.core.RuntimeDroolsException: > java.lang.reflect.InvocationTargetException : [Rete(0)] > And the Rete Tree is not displayed. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1733) UNICAST3: OOB messages should be marked as OOB_DELIVERED before adding them to the table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1733: --------------------------- Fix Version/s: 3.4.1 > UNICAST3: OOB messages should be marked as OOB_DELIVERED before adding them to the table > ---------------------------------------------------------------------------------------- > > Key: JGRP-1733 > URL: https://issues.jboss.org/browse/JGRP-1733 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4.1, 3.5 > > > Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up. > However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery. > This is the same though if a batch only contains regular messages... > However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2463) Set Strict-Transport-Security in HTTP-Header

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2463?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-2463: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > Set Strict-Transport-Security in HTTP-Header > -------------------------------------------- > > Key: WFLY-2463 > URL: https://issues.jboss.org/browse/WFLY-2463 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Tomaz Cerar > > It would be good to set the http Header "Strict-Transport-Security: max-age=<SECONDS>" in Undertow -- 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

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013