Посредник кеша не возвращает кешированный ответ в EI 6.1

Я пытаюсь добавить функцию кеширования в свою службу, представленную как API, чтобы повторяющиеся запросы получали кешированный ответ. Но вместо кешированного ответа посредник возвращает мне сообщение, отправленное клиентом.
Здесь следует конфигурация моего API. Он описывает ресурс получения, который получает два параметра запроса и использует их для создания payoad, который он отправляет в локальную службу dss:

    <?xml version="1.0" encoding="UTF-8"?>
<api context="/config" name="myAPI" xmlns="http://ws.apache.org/ns/synapse">
    <resource methods="GET">
        <inSequence>
            <cache collector="false" hashGenerator="org.wso2.carbon.mediator.cache.digest.DOMHASHGenerator" id="testCache" scope="per-mediator" timeout="200">
                <onCacheHit/>
                <implementation maxSize="100" type="memory"/>
            </cache>
            <property expression="$url:intg" name="uri.integration" scope="default" type="STRING"/>
            <property expression="$url:inst" name="uri.institution" scope="default" type="STRING"/>
            <payloadFactory media-type="xml">
                <format>
                    <con:show xmlns:con="http://com.dvg.wso2/configservice">
                        <con:SEL_INTG_NAME>$1</con:SEL_INTG_NAME>
                        <con:SEL_INSTITUTION>$2</con:SEL_INSTITUTION>
                    </con:show>
                </format>
                <args>
                    <arg evaluator="xml" expression="get-property('uri.integration')"/>
                    <arg evaluator="xml" expression="get-property('uri.institution')"/>
                </args>
            </payloadFactory>
            <header name="Action" scope="default" value="urn:show"/>
            <send>
                <endpoint>
                    <address format="soap11" uri="local:///services/INTG_DVG_ConfigService/"/>
                </endpoint>
            </send>
        </inSequence>
        <outSequence>
            <cache collector="true" scope="per-mediator" id="testCache"/>
            <send/>
        </outSequence>
        <faultSequence/>
    </resource>
</api>

Мой ожидаемый результат должен быть примерно таким:

<soapenv:Body>
    <properties>
        <property>
          <key>A</key>
          <value>A</value>
        </property>
    </properties>
</soapenv:Body>

Но я получаю такой кешированный ответ:

<con:show xmlns:con="http://com.dvg.wso2/configservice"><con:SEL_INTG_NAME>A</con:SEL_INTG_NAME><con:SEL_INSTITUTION>A</con:SEL_INSTITUTION></con:show>

Что и является содержанием полезной нагрузки, которую я создаю в своей последовательности. Следует отметить, что я получаю ожидаемый ответ в случае промаха кеша.

Разве посредник кеша, настроенный как есть, не должен сохранять ответ о промахе кеша и возвращать его в случае попадания в кеш?
Почему он отвечает неправильным контентом?

--- Изменить ---
После изменения конфигурации журнала org.wso2.carbon.mediator.cache.CacheMediator я смог подтвердить, что посредник кеша действительно сохраняет и восстанавливает входное сообщение вместо ответа .
Этого не происходит, если я пытаюсь воспроизвести его в proxyService, только в API.


wso2 wso2esb wso2ei wso2dss
person Rodrigo Vasconcelos    schedule 02.05.2017    source источник
comment
Может быть, из-за типа кеша, ваш случай - это искатель (он кеширует входящее сообщение, а не ответ)   -  person simar    schedule 03.05.2017
comment
@simar Разве для работы кеша нам не нужна пара сборщиков / поисковиков? Один для поиска хэша запроса входящих сообщений, а другой для сбора ответных сообщений в кеше?   -  person Rodrigo Vasconcelos    schedule 03.05.2017
comment
Вы правы, я не обратил внимания на чтение документации.   -  person simar    schedule 03.05.2017
comment
Самый простой способ отладки - переопределить onCacheHit и добавить собственный HTTP-заголовок, например, «Cache-Hit: true». Это поможет убедиться, что вы получаете сообщение из кеша и что правильное сообщение было помещено в него ранее.   -  person simar    schedule 03.05.2017
comment
Убедитесь, что между запросами достаточно тайм-аута   -  person simar    schedule 03.05.2017
comment
Посредник last payloadFactory непонятно зачем. Он вставляет тело в тело сообщения с тегом body, содержащим тело полученного сообщения.   -  person simar    schedule 03.05.2017
comment
Вы можете получить содержимое сообщения, используя выражение xpath $ body / *   -  person simar    schedule 03.05.2017

Ответы (1)


arrow_upward
0
arrow_downward

Мне не удалось заставить кеш-посредник работать в api, но я заметил, что он ведет себя так, как ожидалось, когда реализован в прокси-сервисе.
Итак, я закончил рефакторинг моей интеграции, чтобы api вызывал прокси-сервис, и затем этот прокси проверит кеш перед вызовом службы dss.
Поскольку вызов прокси и dss использует локальный транспорт, это не сильно повлияет на производительность.
Если кто-то читает это в в будущем и получить представление о том, как правильно использовать посредник кеша в службе API, оставьте комментарий.

person Rodrigo Vasconcelos    schedule 09.05.2017