[
https://issues.apache.org/jira/browse/GEODE-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090193#comment-16090193
]
ASF subversion and git services commented on GEODE-3139:
--------------------------------------------------------
Commit 30e2eb2080afff3af2f5226a412259c3a5302f63 in geode's branch
refs/heads/master from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=30e2eb2 ]
GEODE-3139 remove artifacts from classpath of backward-compatibility tests
reinstating this - passes precheckin
GEODE-3153 Client receives duplicate events during rolling upgrade
Another problem was found in backward-compatibility testing. If a
1.0.0 client was receiving subscription events generated by a 1.0.0
peer "feeder" member and the events were routed through a 1.0.0 server
the client might see duplicate events when the server is stopped and
the client fails over to a 1.2.0 server holding its redundant
subscription queue. This is especially possible if a large "ack"
period is established in the client.
The problem stems from the EventID deserialization/reserialization of
the memberID bytes when sending to a 1.0 client. It was deserializing
using Version.CURRENT, which ignores the UUID bytes in the serialized ID.
Then it serialized the identifier using the client's version, which
includes the UUID bytes but which are zero due to the version used
in deserialization.
> remove geode-core/src/main artifacts from classpath of backward-compatibility
> tests
> -----------------------------------------------------------------------------------
>
> Key: GEODE-3139
> URL: https://issues.apache.org/jira/browse/GEODE-3139
> Project: Geode
> Issue Type: Bug
> Components: build
> Reporter: Bruce Schuchardt
> Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> When a JVM is launched to run an old version of GEODE its classpath currently
> includes the old version's jars but also includes the current version's
> classes, resources and generated-resources directories. This could cause the
> JVM to function differently than expected if the test happens to reference
> some new class or an API that doesn't exist in the old version.
> I removed these directories from the classpath and found that the tests all
> break when the couldn't find InternalClientCache, a new interface that is now
> referenced by the test framework.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
