October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1710: -------------------------------- As a quickfix, we could place a *second* FRAG2 just above the transport: if VIEW and INSTALL_MERGE_VIEW etc carry their payload in the message's body instead of the header, then that second FRAG2 would fragment the message again. As a long term solution we should investigate whether FRAG2 cannot be *moved* (instead of duplicated) just above the transport. > Messages get too large due to big headers (in large clusters) > ------------------------------------------------------------- > > Key: JGRP-1710 > URL: https://issues.jboss.org/browse/JGRP-1710 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In some cases, messages get bigger than the max bundling size because of large headers: > {panel} > ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... > {panel} > In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. > Possible SOLUTION > * Place the header fields in the message's buffer instead > * Move FRAG2 *under* GMS > ** Investigate impact on flow control etc -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-216) Map accessors and custom evaluators do not work together

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-216?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-216: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Map accessors and custom evaluators do not work together > -------------------------------------------------------- > > Key: DROOLS-216 > URL: https://issues.jboss.org/browse/DROOLS-216 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > > Map( this[ "x" ] custOp value ) fails. > The custom evaluator is passed the map itself, rather than the value > corresponding to the key. -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-217) MVEL throws an exception when using bound variables and map accessors

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-217?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-217: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > MVEL throws an exception when using bound variables and map accessors > --------------------------------------------------------------------- > > Key: DROOLS-217 > URL: https://issues.jboss.org/browse/DROOLS-217 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > > Map( $c : this[ "x" ], $c op value ) > throws an exception as MVEL tries to compile the constraint -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when inserting throw Expression with Java 7

by Aftab Khan (JIRA)

[ https://issues.jboss.org/browse/JASSIST-207?page=com.atlassian.jira.plugi... ] Aftab Khan commented on JASSIST-207: ------------------------------------ The issue has been resolved and working in javassist-3.18.1-GA. Thanks, Aftab > Inconsistent Stack Map when inserting throw Expression with Java 7 > ------------------------------------------------------------------ > > Key: JASSIST-207 > URL: https://issues.jboss.org/browse/JASSIST-207 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.18.0-GA > Reporter: Ben Romberg > Assignee: Shigeru Chiba > Priority: Critical > Fix For: 3.18.1-GA, 3.19.0-GA > > Attachments: afterInsertThrowExpression.txt, AGDelegateImpl.class, beforeInsertThrowExpression.txt, conditionalThrowExceptionInserted.txt > > > I wrote a unit-test for javassist, reproducing the issue: > {code} > public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot { > public ThrowExpressionCorruptsStackMapTableTest(String name) { > super(name); > } > public void testInsertLocalVars() throws Exception { > CtClass cc = sloader.get("test4.LocalVars"); > CtMethod m1 = cc.getDeclaredMethod("run"); > m1.insertBefore("throw new AssertionError((Object) \"assertion error\");"); > cc.writeFile(); > Object obj = make(cc.getName()); > assertEquals(10, invoke(obj, "run")); > } > } > {code} > Throws: > java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45 > My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message: > Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27 -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1710: --------------------------- Description: In some cases, messages get bigger than the max bundling size because of large headers: {panel} ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... {panel} In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. Possible SOLUTION * Place the header fields in the message's buffer instead * Move FRAG2 *under* GMS ** Investigate impact on flow control etc was: In some cases, messages get bigger than the max bundling size because of large headers: {noformat} ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... {noformat} In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. Possible SOLUTION * Place the header fields in the message's buffer instead * Move FRAG2 *under* GMS ** Investigate impact on flow control etc > Messages get too large due to big headers (in large clusters) > ------------------------------------------------------------- > > Key: JGRP-1710 > URL: https://issues.jboss.org/browse/JGRP-1710 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In some cases, messages get bigger than the max bundling size because of large headers: > {panel} > ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... > {panel} > In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. > Possible SOLUTION > * Place the header fields in the message's buffer instead > * Move FRAG2 *under* GMS > ** Investigate impact on flow control etc -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1710: -------------------------------- In general, headers should be relatively small as fragmentation is based on a message's *buffer* (payload) and doesn't take the headers into account until the transport is reached where the *full size* (including the headers) is computed. If the headers add a lot to the total size, then the transport might have to discard the message. > Messages get too large due to big headers (in large clusters) > ------------------------------------------------------------- > > Key: JGRP-1710 > URL: https://issues.jboss.org/browse/JGRP-1710 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In some cases, messages get bigger than the max bundling size because of large headers: > {noformat} > ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... > {noformat} > In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. > Possible SOLUTION > * Place the header fields in the message's buffer instead > * Move FRAG2 *under* GMS > ** Investigate impact on flow control etc -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1710: --------------------------- Description: In some cases, messages get bigger than the max bundling size because of large headers: {noformat} ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... {noformat} In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. Possible SOLUTION * Place the header fields in the message's buffer instead * Move FRAG2 *under* GMS ** Investigate impact on flow control etc was: In some cases, messages get bigger than the max bundling size because of large headers: {noformat} ERROR Sep 30 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... {noformat} In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. Possible SOLUTION * Place the header fields in the message's buffer instead * Move FRAG2 *under* GMS ** Investigate impact on flow control etc > Messages get too large due to big headers (in large clusters) > ------------------------------------------------------------- > > Key: JGRP-1710 > URL: https://issues.jboss.org/browse/JGRP-1710 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In some cases, messages get bigger than the max bundling size because of large headers: > {noformat} > ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... > {noformat} > In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. > Possible SOLUTION > * Place the header fields in the message's buffer instead > * Move FRAG2 *under* GMS > ** Investigate impact on flow control etc -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)

by Bela Ban (JIRA)

Bela Ban created JGRP-1710: ------------------------------ Summary: Messages get too large due to big headers (in large clusters) Key: JGRP-1710 URL: https://issues.jboss.org/browse/JGRP-1710 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.4 In some cases, messages get bigger than the max bundling size because of large headers: {noformat} ERROR Sep 30 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ... {noformat} In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size. Possible SOLUTION * Place the header fields in the message's buffer instead * Move FRAG2 *under* GMS ** Investigate impact on flow control etc -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-88) Support generics in declared types' fields

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.... ] Michael Biarnes Kiefer updated DROOLS-88: ----------------------------------------- Fix Version/s: 6.0.0.CR5 (was: 6.0.0.CR4) > Support generics in declared types' fields > ------------------------------------------ > > Key: DROOLS-88 > URL: https://issues.jboss.org/browse/DROOLS-88 > Project: Drools > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 5.5.1.Final, 6.0.0.CR5 > > > It should be possible to write: > declare Foo > list : List<String> > end > While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules. > Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-238) (Trait) hierarchy indexing and lookup is dramatically slower than needed

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-238?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-238: ------------------------------------------ Fix Version/s: 6.0.0.CR5 (was: 6.0.0.CR4) > (Trait) hierarchy indexing and lookup is dramatically slower than needed > ------------------------------------------------------------------------ > > Key: DROOLS-238 > URL: https://issues.jboss.org/browse/DROOLS-238 > Project: Drools > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.CR1 > Reporter: Davide Sottara > Assignee: Mark Proctor > Priority: Critical > Fix For: 5.5.1.Final, 6.0.0.CR5 > > > The encoding is not optimized for performance, and suffers particularly in case of large, flat taxonomies -- 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

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013