geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-3139) remove geode-core/src/main artifacts from classpath of backward-compatibility tests
Date Mon, 17 Jul 2017 18:07:01 GMT


ASF subversion and git services commented on GEODE-3139:

Commit 30e2eb2080afff3af2f5226a412259c3a5302f63 in geode's branch refs/heads/master from [~bschuchardt]
[;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:
>             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

This message was sent by Atlassian JIRA

View raw message