Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info
W czwartek 13 sierpnia 2015 r. udostępniliśmy poprawkę do Apigee Edge Private Cloud WebSockets.
Nowe funkcje i ulepszenia
Poniżej znajdziesz nowe funkcje i ulepszenia w tej wersji.
Dostosowywanie rozmiaru ramki WebSocket
Możesz skonfigurować rozmiar ramek WebSocket w Apigee Edge Private Cloud. Aby to zrobić, skonfiguruj właściwości w 2 różnych plikach na wszystkich routerach i procesorach wiadomości. Wartości w obu plikach muszą być zawsze zgodne.
- W pliku router.properties routera skonfiguruj:
WEBSOCKET.frame.limit=4k - W pliku netty-websocket-adaptor.properties procesora wiadomości skonfiguruj:
netty.websocket.message.max.frame.length=4k
Po zaktualizowaniu plików uruchom ponownie węzły routera i procesora wiadomości. Na przykład:
/<inst-root>/apigee4/bin/apigee-service router restart
/<inst-root>/apigee4/bin/apigee-service message-processor restart
(APIRT-1806)
zmienne przepływu celu nie są prawidłowo wypełniane w przypadku celu wbudowanego i serwerów docelowych;
Nowe zmienne w przepływach wiadomości zawierają pełniejsze informacje o adresach URL docelowych punktów końcowych i serwerów docelowych:
- TargetEndpoint: request.url zastępuje target.basepath.with.query.
- TargetServer: loadbalancing.targetserver zastępuje targetserver.name. Poza tym zmienna target.basepath jest wypełniana tylko wtedy, gdy element <Path> jest używany w elemencie <LoadBalancer> w HTTPTargetConnection w TargetEndpoint. (APIRT-1050)
Usunięte błędy
W tej wersji naprawiliśmy te błędy:
| Identyfikator problemu | Opis |
|---|---|
| TBD-82 | Po zmianie hasła systemowego nie powiodły się autotesty serwera zarządzania |
| MGMT-2551 | Interfejs w wersji 4.15.04.03 nie działa już z Java 6 |
| MGMT-2418 | Plik apigee.conf konfiguracji interfejsu nie obsługuje TLS |
| MGMT-2255 | Po zmianie hasła systemowego nie powiodły się autotesty serwera zarządzania |
| MGMT-1677 | Rejestrowanie w trybie debugowania błędów uwierzytelniania i autoryzacji |
| CORERT-318 | HTTPServer.streaming.buffer.limit=10 powodował sporadyczne zawieszanie się żądań Podczas obsługi wolnych klientów i dużych ładunków żądania czasami zawieszały się i przekraczały limit czasu w routerze. Ten problem występował tylko wtedy, gdy właściwość HTTPServer.streaming.buffer.limit routera miała wartość inną niż zero. Problem został rozwiązany. |
| APIRT-1766 | Przekroczenie limitu czasu w przypadku WebSockets |
| APIRT-1713 | Błędy zasad ExtractVariables przy obciążeniu 10 transakcji na sekundę |
| APIRT-1472 | Wiadomości w pliku system.log za każdym razem, gdy wywoływany jest interfejs API kontroli stanu |
| APIRT-1147 | Przesyłanie strumieniowe danych proxy z zasobnika S3 nie kończy już pobierania |