[JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1507 at 10/1/13 6:54 AM:
---------------------------------------------------------
h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.
The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...
Downside: if we have a large message P:5 and FRAG2 generates 100 fragments, if at least 1 fragment is lost, the receiver will ask P to retransmit message 5, resulting in re-sending of P:5 and - due to fragmentation - sending of another 100 fragments.
So, in the worst case, losing 1 fragments causes the resending of 100 fragments. Not a good idea...
was (Author: belaban):
h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.
The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...
> MFC2: multicast flow control
> ----------------------------
>
> Key: JGRP-1507
> URL: https://issues.jboss.org/browse/JGRP-1507
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss.
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB
--
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
[JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1507:
--------------------------------
h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.
The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...
> MFC2: multicast flow control
> ----------------------------
>
> Key: JGRP-1507
> URL: https://issues.jboss.org/browse/JGRP-1507
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss.
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB
--
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
[JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1960:
-----------------------------------------------
Stuart Douglas <sdouglas(a)redhat.com> made a comment on [bug 1001610|https://bugzilla.redhat.com/show_bug.cgi?id=1001610]
Rejecting dev_ack as per Martin's comment, as the test is invalid.
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
> Key: WFLY-1960
> URL: https://issues.jboss.org/browse/WFLY-1960
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Reporter: Aslak Knutsen
> Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work.
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>
> @Stateless
> @WebService
> public class TestBean {
> }
>
>
> import javax.inject.Inject;
>
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>
>
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>
> @Inject
> TestBean bean;
>
> @Deployment
> public static WebArchive createDeployment() {
> WebArchive arch = ShrinkWrap.create(WebArchive.class);
> arch.addClass(TestBean.class);
> arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
> return arch;
> }
>
> @Test
> public void fooTest() throws Exception {
>
> }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>
> @EJB
> TestBean bean;
> ...
> }
> {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
10 years, 6 months
[JBoss JIRA] (WFLY-794) javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reopened WFLY-794:
---------------------------------
Assignee: Stuart Douglas (was: Bartosz Baranowski)
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-794
> URL: https://issues.jboss.org/browse/WFLY-794
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Alex Corvino
> Assignee: Stuart Douglas
> Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown.
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final).
> Note that this behavior is NOT seen when connecting to another JBoss server.
> Full stack trace:
> {code}
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> ... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> ... 37 more
> {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
10 years, 6 months
[JBoss JIRA] (WFLY-2190) Priviledge alignment for scoped resources
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.... ]
Heiko Braun updated WFLY-2190:
------------------------------
Description:
server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}?
was:
server-groups show different privildges for server-group=* and server-group=<specific instance>. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
wouldit be possible that the operation permissions for server-group=<specific instance>:<add|remove> show the same permissions as server-group=*:<add|remove>?
> Priviledge alignment for scoped resources
> -----------------------------------------
>
> Key: WFLY-2190
> URL: https://issues.jboss.org/browse/WFLY-2190
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 8.0.0.CR1
>
>
> server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
> Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}?
--
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
[JBoss JIRA] (WFLY-2190) Priviledge alignment for scoped resources
by Heiko Braun (JIRA)
Heiko Braun created WFLY-2190:
---------------------------------
Summary: Priviledge alignment for scoped resources
Key: WFLY-2190
URL: https://issues.jboss.org/browse/WFLY-2190
Project: WildFly
Issue Type: Enhancement
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 8.0.0.CR1
server-groups show different privildges for server-group=* and server-group=<specific instance>. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges.
wouldit be possible that the operation permissions for server-group=<specific instance>:<add|remove> show the same permissions as server-group=*:<add|remove>?
--
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
[JBoss JIRA] (WFLY-2058) Standalone profile hangs using Java 8 developer preview
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-2058:
-------------------------------
Issue Type: Bug (was: Feature Request)
Priority: Major (was: Minor)
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
> Key: WFLY-2058
> URL: https://issues.jboss.org/browse/WFLY-2058
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Alpha4
> Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
> Reporter: Gerard Krupa
> Assignee: Jason Greene
> Labels: hangs, java8, jdk8, standalone.bat
> Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties
--
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
[JBoss JIRA] (WFLY-2058) Standalone profile hangs using Java 8 developer preview
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.... ]
jaikiran pai closed WFLY-2058.
------------------------------
Resolution: Duplicate Issue
Duplicate of WFLY-2057
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
> Key: WFLY-2058
> URL: https://issues.jboss.org/browse/WFLY-2058
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Alpha4
> Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
> Reporter: Gerard Krupa
> Assignee: Jason Greene
> Labels: hangs, java8, jdk8, standalone.bat
> Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties
--
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
[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:
---------------------------
Workaround Description: Place *FRAG* just above the transport. FRAG (in contrary to FRAG2) uses {{Message.size()}} to determine whether a message needs to be fragmented, and therefore takes headers into account, too.
Workaround: Workaround Exists
> 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