GitHub user alt-freem opened a pull request:

    https://github.com/apache/ignite/pull/1869

    Ignite 3935

    Это не PullRequest, в том смысле что задача не 
выполнена, PR завел просто как площадку для 
обсуждения и возможности комментировать 
по коду.
    Тут находится грязный код моих попыток 
воспроизвести проблему, код не причесывал, 
так задача технически не решена и нет 
особого смысла это делать.
    Удалось воспроизвести проблему на 
описанном в тикете примере, в случае когда 
Клинет и Сервер стартуют в разных jvm и имеют 
разные classpath, то есть на сервере явно 
отсутствует клиентская реализация 
CacheEntryProcessor.
    
    Проблема, я полагаю в методе 
GridDeploymentManager#getGlobalDeployment - там есть 
оптимизация которая сначала ищет 
переданный от клиента класс в localDeployment и 
если его находит, то дальнейшую 
десериализацию ответа проводит с classloader'ом 
localDeployment'а, это приводит к проблемам в 
описанном случае: в localDeployment находиться 
StreamTrasformer$1 внутри которого ссылка не 
клиентский класс реализации CacheEntryProcessor, 
соответственно дессериализация 
разваливается.
    Меня смущает что код 
GridDeploymentManager#getGlobalDeployment не менялся с 14го 
года, то есть вроде как стабильный и вроде 
как должен быть рабочим, в тоже время я не 
нашел на него каких либо тестов которые 
как-то проверяли бы его корректность.
    В любом случае подобная оптимизация мне 
кажется сомнительной, как решение я бы 
предложил выпилить всю ветку вокруг 
переменной <code>boolean reuse = true</code> и безусловно 
возвращать <code>verStore.getDeployment(meta)</code>.
    Classloader которого мог бы иметь parent'ом - 
localDeployment.classloader.
    Таким образом GridDeploymentClassLoader
    <ul>
    <li/><i>StreamTrasformer$1</i> загрузит из локального 
classloader'а 
    <li/> а связанную с ним реализацию 
<i>CacheEntryProcessor</i> (не найдя в локальном) 
загрузит запросом с клиента
    </ul>
    Собственно эксперимент на отдельных JVM 
это подтвердил (классы Client, Server), 
существующий набор тестов пакета 
<i>org.apache.ignite.internal.processors.datastreamer</i> прошел без 
изменений.
    
    Когда начал все это заворачивать в один 
junit тест возникли проблемы с тем что клиент 
ignite то тут то там цеплял не тот classloder' 
который мне был нужен,
    <b>например</b> в качестве базового classloader'a 
клиент перед отправкой стрима на сервер 
выбирал не тот classloader которым был загружен 
передаваемый объект, тот которым был 
загружен первый <i>nonJdk</i> класс связанный с 
передаваемым объектом.
    <i>DataStreamerPda#deployClass</i>
    ```java
    for (Iterator<Object> it = objs.iterator(); (cls0 == null || U.isJdk(cls0)) 
&& it.hasNext(); ) {
        Object o = it.next();
        if (o != null)
            cls0 = U.detectClass(o);
    }
    ```
    Такого рода проблем было несколько и я не 
успел их решить.
    Над задачей работал Сб. и Вс. ну и сегодня 
вот резюме оформил ещё минут 30.
    Заниматься задачей на буднях - нет 
времени, тратить еще одни выходные - нет 
желания.


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/alt-freem/ignite IGNITE-3935

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/ignite/pull/1869.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1869
    
----
commit fd2f31dc678ff83df7eef7056ec184a5e963e710
Author: freem <[email protected]>
Date:   2017-04-23T10:21:31Z

    IGNITE-3935: reloadingClassLoader

commit 6b78256168e5a2957d1511469745ec3c3cceabb4
Author: freem <[email protected]>
Date:   2017-04-23T12:39:08Z

    IGNITE-3935: new client-test-module

commit 0f79ec2b2b88ae17a89d03851369d2b0042f1b70
Author: freem <[email protected]>
Date:   2017-04-23T16:50:44Z

    IGNITE-3935: disable local deployment optimisation on 
GridDeploymentManager.getGlobalDeployment

commit 6b9613bbdc839594bd4eeee609ef535d92cff0a4
Author: freem <[email protected]>
Date:   2017-04-25T09:38:11Z

    IGNITE-3935: attempt to load 2 ingnte instances with different class loaders

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to