[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1875:
--------------------------------
We don't even need {{nanoTime()}} (a long and a system call): we could use an {{AtomicInteger}}, as a field of UNICAST3, and every {{getTime()}} would simply increment it. This would give us unique and increasing timestamps for each receiver. If a receiver is restarted/reconnected, we have a new UUID and therefore a new time source.
Using ints instead of longs would reduce memory requirements and sending (_compressed_) ints around also saves on network bandwidth.
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Tomas Sykora (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Tomas Sykora commented on WFLY-3756:
------------------------------------
Unfortunately not any sophisticated solution, just:
https://github.com/infinispan/infinispan/blob/master/server/integration/t...
We simply start / kill our "old" infinispan-server using maven-antrun-plugin. "New" infinispan-servers (based on Wildfly) are managed using Arquillian.
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Karel Piwko commented on WFLY-3756:
-----------------------------------
@Tomas Sykora, can you share details how you did that? Will your solution help other people having both AS7/WF8 on the classpath and using both containers simultaneously?
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-673) The exception chain of DeploymentException never contains the actual cause
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-673?page=com.atlassian.jira.plugin.s... ]
Martin Kouba commented on WFLY-673:
-----------------------------------
[~struberg] This is more an issue of the WildFly exception reporting and WildFly Arquillian container adapter, not the Arquillian core/SPI. We use a simple workaround - custom DeploymentExceptionTransformer - in the Weld TCK runner:
https://github.com/weld/core/blob/master/jboss-tck-runner/1.1/src/test/ja...
> The exception chain of DeploymentException never contains the actual cause
> --------------------------------------------------------------------------
>
> Key: WFLY-673
> URL: https://issues.jboss.org/browse/WFLY-673
> Project: WildFly
> Issue Type: Bug
> Reporter: Jason Porter
> Fix For: No Release
>
>
> You can see the exception here:
> -------------------------------------------------------------------------------
> Test set: org.jboss.seam.exception.control.test.extension.ExtensionErrorTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.711 sec <<< FAILURE!
> org.jboss.seam.exception.control.test.extension.ExtensionErrorTest Time elapsed: 0 sec <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container
> at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:111)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:148)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:115)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:246)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:114)
> 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:86)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:238)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:222)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78)
> 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:97)
> 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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
> 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
> Caused by: java.lang.Exception: {
> "Failed services" => {"jboss.deployment.unit.\"extensionError.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"extensionError.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> java.lang.IllegalArgumentException: Handler method public void org.jboss.seam.exception.control.test.handler.HandlerWhichThrowsExceptions.throwsAnException(org.jboss.seam.exception.control.CaughtException) throws java.lang.Exception must not throw exceptions
> at org.jboss.seam.exception.control.extension.CatchExtension.findHandlers(CatchExtension.java:93)
> at sun.reflect.GeneratedMethodAccessor413.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
> at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
> at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
> at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
> at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:67)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:34)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:126)
> at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370)
> at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
> at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> "},
> "Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".WeldInstantiator",
> "jboss.deployment.unit.\"extensionError.war\".jndiDependencyService",
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".START",
> "jboss.web.\"extensionError.war\"",
> "jboss.naming.context.java.module.extensionError.extensionError.BeanManager",
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".START",
> "jboss.deployment.unit.\"extensionError.war\".beanmanager",
> "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".WeldInstantiator"
> ]
> }
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:99)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:88)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:70)
> at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:75)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:56)
> ... 88 more
> The exception I'm expecting is the DefinitionException, not java.lang.Exception. Understandably it may not be correct to pass back the actual exception without wrapping it, but wrapping in java.lang.Exception doesn't really cut it either.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1875:
--------------------------------
Or should we make {{conn-id}} a long and use {{nanoTime()}} to set it ? This would guarantee that conn-ids can compare conn-ids and discard messages sent with previous conn-ids. Also, we wouldn't have to add another long, but turn the short conn-id into a long...
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1875:
--------------------------------
Perhaps a simpler solution is to use _timestamps_ for {{SEND-GET-FIRST}} and {{STABLE}} messages from B to A.
Timestamps could be generated using {{System.nanoTime()}}, which would guarantee that they always increase. The sender (A) keeps the last timestamp received from B, and drops all {{STABLE}} messages from B which are <= its current timestamp for B.
This solution would require minimal changes to UNICAST3 and a backport to UNICAST2 would be minimally invasive, too. Also, it would include traffic reduction as detailed in JGRP-1874, by resending {{GET-FIRST-SEQNO}} via a timer task.
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month