[infinispan-issues] [JBoss JIRA] (ISPN-5107) UNICAST3 and NAKACK2 table sizes are too big

[Dan Berindei (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Berindei updated ISPN-5107:
-------------------------------
    Status: Open  (was: New)


> UNICAST3 and NAKACK2 table sizes are too big
> --------------------------------------------
>
>                 Key: ISPN-5107
>                 URL: https://issues.jboss.org/browse/ISPN-5107
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>             Fix For: 7.1.0.Beta1
>
>
> This is the default configuration we use for UNICAST3 and NAKACK2:
> {code:xml}
>    <pbcast.NAKACK2
>                     xmit_interval="1000"
>                     xmit_table_num_rows="100"
>                     xmit_table_msgs_per_row="10000"
>                     xmit_table_max_compaction_time="10000"
>                     max_msg_batch_size="100"
>                     resend_last_seqno="true"/>
>    <UNICAST3
>               xmit_interval="500"
>               xmit_table_num_rows="20"
>               xmit_table_msgs_per_row="10000"
>               xmit_table_max_compaction_time="10000"
>               max_msg_batch_size="100"
>               conn_expiry_timeout="0"/>
> {code}
> Bela recommended making a smaller `xmit_table_msgs_per_row`:
> {quote}
> Wow. I suggest 50 * 1024 or 20 * 2048 is good enough, as the table will expand/shrink on demand anyway.
> Note that you can also set xmit_table_max_compaction_time, but I would use the default (30s / 60s).
> \[...\]
> The \[number of rows\] is not the problem, as JGroups will dynamically create more, or remove unused ones when compacting, but the size of the rows is static.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)