Пулы JMS-соединений и их использование с WebSphere Application Server и WebSphere MQ, Часть 1

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Пол Тизеридж, Level 3 Service, IBM WebSphere and Java Messaging Support

24.10.2007

В этой серии статей из двух частей рассказывается, как работает пул JMS-соединений в WebSphere Application Server и WebSphere MQ. В первой части описывается, как использовать пулы свободных соединений, как управлять содержимым пула и как совместно работают различные свойства пула.

Введение

В целях повышения производительности IBM® WebSphere® Application Server поддерживает пул соединений к JMS-провайдеру. Когда приложение создает JMS-соединение, сервер приложений определяет, имеется ли соединение в пуле свободных соединений. Если да, оно возвращается в приложение. В противном случае создается новое соединение. Но как на самом деле работает пул свободных соединений?

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

Пулы JMS-соединений

В общих чертах, пул соединения - это пул свободных соединений с JMS-провайдером. JMS использует концепцию фабрик соединений, которые используются для создания соединений с JMS-провайдерами. WebSphere Application Server имеет ограничение по количеству соединений, которые можно создать из фабрики, указанное в свойстве Connection Factory’s Maximum connections. Значением по умолчанию является 10. Это означает, что из фабрики можно одновременно создать до 10 соединений.

Каждая фабрика имеет свой пул свободных соединений. После начала работы сервера приложений пулы свободных соединений пусты. Максимальное количество соединений, которые могут существовать в пуле свободных соединений для фабрики, тоже указывается в свойстве Maximum connections. На рисунке 1 показаны пулы JMS-соединений в сервере приложений, в котором определены три фабрики соединений:

Как используются пулы соединений

Когда приложение, работающее на сервере приложений, использует фабрику для создания соединения (например, путем вызова connectionFactory.createConnection()), WebSphere Application Server Connection Manager попытается получить соединение из пула свободных соединений для этой фабрики и возвратить его приложению. Если в пуле нет свободных соединений, и количество соединений от этой фабрики не превысило предела, указанного в свойстве Factory's Maximum connections, Connection Manager создаст новое соединение для использования приложением.

Что произойдет, если приложение попытается создать соединение, но количество соединений, созданных из этой фабрики, уже равно значению, указанному в свойстве Factory's Maximum connections? Хороший вопрос!

В этой ситуации приложение ожидает, пока соединение не станет доступным (не будет возвращено в пул свободных соединений). Время ожидания указывается в свойстве Connection Pool's Connection timeout, значение по умолчанию которого равно 180 секундам (3 мин.). Если соединение возвращается в пул свободных соединений в пределах этих 3 минут, Connection Manager немедленно извлекает его из пула и передает в приложение. Однако если таймаут истекает, генерируется исключительная ситуация ConnectionWaitTimeoutException. На рисунке 2 показано, как JMS-соединения извлекаются из пула свободных соединений:

Когда приложение завершает свою работу с соединением и закрывает его путем вызова connection.close(), соединение на самом деле остается открытым, возвращается в пул свободных соединений и может использоваться повторно другим приложением. То есть могут существовать открытые соединения между WebSphere Application Server и JMS-провайдером, даже если на сервере приложений не выполняются JMS-приложения.

Как прослушивающие порты управляемого сообщениями bean-компонента используют пул соединений

Предположим, что имеется управляемый сообщениями компонент (message-driven bean - MDB), развернутый на сервере WebSphere Application Server V6.1 Base system, который использует WebSphere MQ в качестве JMS-провайдера. MDB развернут с прослушивающим портом (listener port) MDBListener1, который использует фабрику соединений Connection Factory jms/CF1. Свойство Maximum connections этой фабрики соединений установлено в значение 2, означая, что только два соединения могут быть созданы из этой фабрики в любой момент времени.

Когда прослушивающий порт начинает работу, он пытается создать соединение с WebSphere MQ, используя фабрику соединений jms/CF1. Для этого он запрашивает соединение у Connection Manager. Поскольку это первый случай использования фабрики соединений jms/CF1, в пуле свободных соединений jms/CF1 нет соединений, поэтому Connection Manager создает новое - c1. Это соединение будет существовать все время работы прослушивающего порта.

Что произойдет, если вы остановите прослушивающий порт, используя WebSphere Administrative Console? В этой ситуации Connection Manager возьмет соединение и поместит его назад в очередь свободных соединений. Соединение с WebSphere MQ остается открытым.

Если прослушивающий порт перезапустить, он опять запросит у Connection Manager соединение с менеджером очередей. Теперь в пуле свободных соединений имеется соединение c1, поэтому Connection Manager возьмет это соединение и сделает его доступным для прослушивающего порта. Теперь предположим, что имеется второй MDB, развернутый на сервере приложений, и он использует другой прослушивающий порт - MDBListener2:

Предположим, что вы пытаетесь запустить третий прослушивающий порт (MDBListener3), который тоже настроен на использование фабрики соединений jms/CF1. Прослушивающий порт запрашивает соединение у Connection Manager, который просматривает пул свободных соединений для jms/CF1 и обнаруживает, что он пуст. Тогда он проверяет, сколько соединений уже было создано из фабрики jms/CF1. Поскольку свойство Maximum connections для jms/CF1 установлено в 2, и вы уже создали два соединения из этой фабрики, Connection Manager будет ждать три минуты (значение свойства Connection timeout по умолчанию), пока соединение не станет доступно:

Что произойдет, если прослушивающий порт MDBListener1 остановить? Его соединение c1 помещается в пул свободных соединений для jms/CF1, Connection Manager извлекает его и передает в MDBListener3:

Теперь, если вы попытаетесь перезапустить MDBListener1, он должен будет подождать, пока один из других наших прослушивающих портов не будет остановлен. Если ни один из работающих прослушивающих портов не будет остановлен в течение трех минут, MDBListener1 получит исключительную ситуацию ConnectionWaitTimeoutException и остановится.

Как Enterprise JavaBeans использует пул соединений

На этот раз давайте предположим, что у нас есть один компонент Enterprise JavaBean (EJB) с названием EJB1, установленный на сервере приложений. Компонент реализует метод sendMessage(), который ведет себя следующим образом:

• Создает JMS-соединение с WebSphere MQ из фабрики jms/CF1, вызывая connectionFactory.createConnection().
• Создает JMS-сессию из соединения.
• Создает поставщика сообщений (message producer) из сессии.
• Передает сообщение.
• Закрывает поставщика сообщений.
• Закрывает сессию.
• Закрывает соединение, вызывая connection.close().

Предположим, что пул свободных соединений для фабрики jms/CF1 пуст. Когда EJB активизируется в первый раз, он пытается создать соединение с WebSphere MQ из фабрики jms/CF1. Поскольку пул свободных соединений для фабрики пуст, Connection Manager создает новое соединение и передает его в EJB1:

До выхода из метода вызывается Connection.close(). Вместо закрытия c1 Connection Manager принимает соединение и помещает его в пул свободных соединений для jms/CF1:

В следующий раз, когда вызывается sendMessage(), метод connectionFactory.createConnection() возвращает c1 в приложение. Теперь предположим, что имеется два экземпляра EJB, работающих одновременно. Когда оба экземпляра вызывают sendMessage(), из фабрики соединений jms/CF1 будут создаваться два соединения:

Теперь предположим, что создается третий экземпляр компонента. Когда EJB3 вызывает sendMessage(), метод вызывает connectionFactory.createConnection() для создания соединения из jms/CF1. Однако в это время имеется два соединения, созданные из jms/CF1, что равно значению свойства Maximum connections для данной фабрики. Следовательно, метод createConnection() ждет три минуты (значение свойства Connection timeout фабрики), пока не станет доступно соединение:

Что произойдет, если метод EJB1 sendMessage() вызовет connection.close() и возвратит управление? Используемое им соединение c1 помещается назад в пул свободных соединений. Connection Manager затем извлекает соединение из пула и передает его в компонент EJB3. Вызванный компонентом метод toconnectionFactory.createConnection() возвращает управление, позволяя завершиться методу sendMessage():

Прослушивающие порты и EJB-компоненты, использующие один и тот же пул соединений

Два приведенных выше примера показывают, как прослушивающие порты и EJB-компоненты могут использовать пул соединений по отдельности. Однако прослушивающий порт и EJB-компонент могут работать совместно на одном и том же сервере приложений и создавать JMS-соединения, используя одну и ту же фабрику соединений. Каковы последствия этого?

Ключевым моментом, о котором нужно помнить, является то, что фабрика соединений совместно используется прослушивающим портом и EJB-компонентом. Например, предположим, что имеются MDBListener1 и EJB1, работающие одновременно, и оба используют фабрику соединений jms/CF1. Это означает, что предельное значение, указанное в свойстве Maximum connections, уже достигнуто. Если вы попытаетесь запустить еще один прослушивающий порт или еще один экземпляр EJB-компонента, они должны будут ждать, пока в пул свободных соединений для jms/CF1 не возвратится соединение:

Потоки поддержки пула свободных соединений

С каждым пулом свободных соединений связан поток поддержки пула (pool maintenance thread - PMT), который следит за пулом, чтобы гарантировать действенность находящихся в нем соединений:

Если поток поддержки пула решит, что соединение в пуле свободных соединений должно быть удалено, он физически закрывает соединение с JMS-провайдером.

Как работает поток поддержки пула?

Поведение потока поддержки пула определяется значением четырех свойств пула соединений:

• Aged timeout: Время, которое соединение будет открытым.
• Minimum connections: Минимальное количество соединений, которое Connection Manager будет хранить в пуле свободных соединений фабрики соединений.
• Reap time: Как часто будет запускаться поток поддержки пула соединений.
• Unused timeout: Как долго соединение будет оставаться в пуле свободных соединений перед его закрытием.

По умолчанию поток поддержки пула запускается каждые 180 секунд (3 минуты), хотя это значение может быть изменено путем установки свойства Reap time пула соединений. Поток поддержки пула просматривает каждое соединение в пуле, проверяет, сколько времени оно находится в пуле, и сколько времени прошло с момента его создания и с момента последнего использования. Если соединение не использовалось дольше, чем указано в свойстве Unused timeout пула соединений, поток поддержки проверяет количество соединений, находящихся в данный момент времени в пуле свободных соединений. Если это количество больше, чем значение свойства Minimum connections, Connection Manager закрывает соединение. Если количество соединений равно значению Minimum connections, соединение не будет закрыто и останется в пуле свободных соединений.

Значение свойства Minimum connections по умолчанию равно 1. Это означает, что Connection Manager всегда будет пытаться хранить в пуле свободных соединений, по крайней мере, одно соединение по соображениям производительности.

Свойство Unused timeout по умолчанию равно 1800 секундам (30 минут). По умолчанию, если соединение помещается назад в пул свободных соединений и не используется повторно, по меньшей мере, 30 минут, оно закрывается, если после его закрытия в пуле останется одно соединение. Эта процедура предотвращает "старение" неиспользуемых соединений. Для отключения этой возможности установите данное свойство в ноль.

Если соединение находится в пуле свободных соединений, а время, прошедшее с момента его создания, превысило значение свойства Aged timeout пула соединений, соединение закрывается независимо от того, сколько времени прошло после его последнего использования. По умолчанию свойство Aged timeout установлено в 0. Это означает, что поток поддержки никогда не будет выполнять эту проверку. Соединения, которые существуют дольше значения, указанного в свойстве Aged timeout, удаляются независимо от того, сколько соединений останется в пуле - свойство Minimum connections здесь не учитывается. Приведенная ниже диаграмма показывает, как поток поддержки пула очищает содержимое пула соединений:

Запрет потока поддержки пула

Как можно заметить, поток поддержки пула выполняет много работы, когда он "просыпается", особенно если в пуле свободных соединений фабрики имеется большое количество соединений.

Например, предположим, что имеется три фабрики JMS-соединений jms/CF1, jms/CF2 и jms/CF3, а для каждой фабрики свойство Maximum connections установлено в значение 10. Каждые три минуты просыпаются три потока поддержки пула и сканируют пулы свободных соединений для фабрик jms/CF1, jms/CF2 и jms/CF3 соответственно. Если свободные пулы имеют много соединений, потоки поддержки будут очень загружены, что может значительно повилять на производительность.

Можно запретить поток поддержки соединений для конкретного пула свободных соединений, установив его свойство Reap time в 0. Запрет потока поддержки пула означает, что соединения никогда не будут закрываться из-за истечения времени Unused timeout. Однако они все еще могут быть закрыты после истечения Aged timeout. Когда приложение завершает работу с соединением, Connection Manager проверяет, сколько времени существует соединение, и если этот период больше чем значение свойства Aged timeout, Connection Manager закрывает соединение вместо возврата его в пул свободных соединений.

Транзакционные последствия Aged timeout

Выше говорилось о том, что свойство Aged timeout указывает, как долго соединение с JMS-провайдером остается открытым перед тем, как его закроет Connection Manager. Его значение по умолчанию равно 0. Это означает, что соединение никогда не будет закрыто по причине его старости. Лучше всего оставить это свойство в значении по умолчанию, поскольку разрешение Aged timeout может повлиять на транзакции при использовании JMS в EJB-компонентах.

В JMS единицей транзакции является JMS-сессия, которая создается из JMS-соединения. Именно JMS-сессия вовлечена в транзакции, а не JMS-соединение. Сервер приложений спроектирован так, что JMS-соединения могут быть закрыты по причине истечения Aged timeout, даже если JMS-сессия, созданная из этого соединения, вовлечена в транзакцию. Закрытие JMS-соединения вызывает откат всей ожидающей фиксации транзакционной работы в JMS-сессиях (как описано в JMS Specification). Однако сервер приложений не будет знать о том, что JMS-сессия, созданная из соединения, больше не действительна. Когда он попытается использовать сессию для фиксации или отката транзакции, возникнет исключительная ситуация IllegalStateException.

Если вы хотите использовать Aged timeout с JMS-соединениями изнутри EJB-компонентов, убедитесь в том, что вся JMS-работа явно зафиксирована в JMS-сессии перед выходом из метода EJB, выполняющего JMS-операции.

Поток поддержки пула

Для того чтобы понять, как работает поток поддержки пула, вернемся к примеру EJB (можно также использовать MDB-компоненты и прослушивающие порты, поскольку все, что действительно нужно - способ получения соединений в пуле свободных соединений). Как вы помните, EJB1 реализует метод под названием sendMessage(), который работает так:

• Создает JMS-соединение из фабрики jms/CF1.
• Создает JMS-сессию из соединения.
• Создает поставщика сообщений из сессии.
• Передает сообщение.
• Закрывает поставщика сообщений.
• Закрывает сессию.
• Закрывает соединение.

Свойство Reap time фабрики соединений настроено на значение по умолчанию 180 секунд (3 минуты), свойство Aged timeout - на значение по умолчанию 0 секунд, а свойство Unused установлено в 300 секунд (5 минут). После начала работы сервера приложений активизируется метод sendMessage(). Он создает соединение, используя фабрику jms/CF1, использует ее для передачи сообщения, а затем вызывает connection.close(), что служит причиной помещения c1 в пул свободных соединений:

Через 3 минуты поток поддержки пула начинает работу и просматривает пул свободных соединений для jms/QCF1. В пуле имеется свободное соединение c1, поэтому поток поддержки смотрит на время, когда соединение было возвращено в пул, и сравнивает его с текущим временем. После помещения соединения в пул свободных соединений прошло три минуты, что меньше значения свойства Unused timeout для jms/CF1. Следовательно, поток поддержки пула оставляет соединение в покое.

Спустя 3 минуты поток поддержки пула запускается снова. Он находит соединение c1 и определяет, что оно находится в пуле уже 360 секунд (6 минут), что больше значения Unused timeout, поэтому Connection Manager закрывает его:

Предположим, что теперь вы снова запускаете sendMessage(). Когда приложение вызывает connectionFactory.createConnection(), Connection Manager создает новое соединение с WebSphere MQ, поскольку пул свободных соединений для фабрики соединений пуст.

Этот пример показал, как поток поддержки использует свойства Reap time и Unused timeout для предотвращения появления устаревших соединений. Вы можете спросить, "Как работает свойство Aged timeout?". Предположим, что свойство Aged timeout было установлено в 300 секунд (5 минут), а свойство Unused timeout установлено в 0:

Метод sendMessage() активизируется и пытается создать соединение из фабрики соединений jms/CF1. Поскольку пул свободных соединений пуст, Connection Manager создает новое соединение c1 и возвращает его в приложение. Когда sendMessage() вызывает connection.close(), c1 помещается обратно в пул свободных соединений.

Три минуты спустя запускается поток поддержки пула. Он находит c1 в пуле свободных соединений и проверяет, сколько времени прошло с момента его создания. Соединение существует три минуты, что меньше значения свойства Aged timeout, поэтому поток поддержки пула оставляет его в покое и засыпает. Минутой позже снова вызывается sendMessage(). На этот раз, вызывая connectionFactory.createConnection(), Connection Manager обнаруживает, что уже существует соединение c1, доступное в пуле свободных соединений для jms/CF1. Он берет c1 из пула и передает его в приложение:

Соединение возвращается в пул свободных соединений, кода завершается метод sendMessage(). Двумя минутами позже опять просыпается поток поддержки пула, сканирует содержимое пула свободных соединений для jms/CF1 и находит c1. Хотя соединение использовалось только 120 секунд назад, поток поддержки пула закрывает его, поскольку оно существует дольше значения Aged timeout:

Как свойство Minimum connections влияет на поток поддержки пула

Используя пример MDB снова, предположим, что имеется два MDB-компонента, развернутые на сервере приложений, и каждый использует отдельный прослушивающий порт. Каждый прослушивающий порт настроен на использование фабрики соединений jms/CF1, свойство Unused timeout которой установлено в значение 120 секунд (2 минуты), свойство Reap time установлено в значение 180 секунд (3 минуты), а свойство Minimum connections установлено в значение 1.

Предположим, что MDBListener1 остановлен, а его соединение c1 возвращено в пул свободных соединений. Три минуты спустя просыпается поток поддержки пула, сканирует содержимое пула свободных соединений для jms/CF1 и обнаруживает, что c1 находится в пуле дольше значения свойства Unused timeout фабрики.

Однако перед закрытием c1 поток поддержки пула проверяет, сколько соединений останется в пуле, если удалить это соединение. Поскольку c1 - это единственное соединение в пуле свободных соединений, Connection Manager не закрывает его, потому что в противном случае оставшееся в пуле количество соединений будет меньше значения свойства Minimum connections:

Предположим, что MDBListener2 остановлен. Пул свободных соединений теперь содержит два свободных соединения - c1 и c2. Три минуты спустя опять начинает работать поток поддержки пула. К этому времени c1 находится в пуле 6 минут, а c2 - 3 минуты.

Поток поддержки пула проверяет c1 и обнаруживает, что он находится в пуле дольше значения свойства Unused timeout. Поток затем проверяет, сколько соединений находится в пуле и сравнивает это количество со значением свойства Minimum connections. Поскольку пул содержит два соединения, а свойство Minimum connections установлено в 1, Connection Manager закрывает c1.

Поток поддержки пула теперь проверяет c2. Оно тоже находится в пуле дольше значения Unused timeout. Однако, поскольку закрытие c2 привело бы к тому, что в пуле осталось бы соединений меньше значения свойства Minimum connections, Connection Manager оставляет его в покое:

Заключение

В данной статье было рассмотрено, как WebSphere Application Server организует пул свободных соединений с JMS-провайдерами, для того чтобы улучшить производительность. Было показано, как EJB-приложения и прослушивающие порты MDB используют пул свободных соединений при создании JMS-соединений, что происходит с этими соединениями, когда приложение и прослушивающий порт завершают работу с ними, и как поток поддержки пула очищает пул свободных соединений для предохранения JMS от "старения". В данной статье было также рассмотрено, как работают некоторые свойства пула соединений.

Во второй части данной серии статей описываются расширенные свойства пула соединений, а также рассматривается, как устаревшие соединения удаляются из пула и как работает система организации пула JMS-соединений WebSphere Application Server, когда в качестве JMS-провайдера используется WebSphere MQ.

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи "Using JMS connection pooling with WebSphere Application Server and WebSphere MQ, Part 1" (EN).
  
  
• Пулы JMS-соединений и их использование с WebSphere Application Server и WebSphere MQ, часть 2 (EN)
  
  
• Настройка WebSphere Application Server для организации обработки сообщений в управляемых сообщениями компонентах в строгом порядке (EN)
  
  
• Как работают MDB-прослушиватели с прослушивающим портом в WebSphere Application Server (EN)
  
  
• Как WebSphere Application Server обрабатывает вредоносные сообщения (EN)
  
  
• Как свойство maximum sessions прослушивающего порта влияет на производительность WebSphere Application Server (EN)
  
  
• Посвященный JMS блог Бобби Вульфа (Bobby Woolf)(EN)
  
  
• Страница ресурсов для разработчиков, использующих WebSphere Application Server (EN)
  Технические ресурсы, помогающие в использовании WebSphere Application Server.
  
  
• Страница продукта WebSphere Application Server
  Описания продукта, новости, информация по обучению, поддержка и многое другое.(EN)
  
  
• Информационный центр WebSphere Application Server
  Единый, основанный на Eclipse Web-портал для всей документации по WebSphere Application Server с концепциями, задачами и справочной информацией по установке, настройке и использованию.(EN)
  
  
• WebSphere Application Server information roadmaps
  Карта статей и ресурсов, помогающих в установке, миграции, администрировании, разработке, поиске неисправностей и освоении используемой технологии.(EN)
  
  
• Библиотека документации по WebSphere Application Server
  Руководства по продукту WebSphere Application Server.(EN)
  
  
• Поддержка WebSphere Application Server
  База данных (с функцией поиска) с информацией о проблемах и их решениях, плюс файлы для загрузки, исправление ошибок, отслеживание проблем и многое другое.(EN)
  
  
• Страница ресурсов для разработчиков, использующих WebSphere MQ
  Технические ресурсы, помогающие в проектировании, разработке и развертывании системы обмена сообщениями на промежуточном уровне с использованием WebSphere MQ для интегрирования приложений, Web-сервисов и транзакций почти на любой платформе.(EN)
  
  
• Страница продукта WebSphere MQ
  Описания продукта, новости, информация по обучению, поддержка и многое другое.
  
  
• Загрузка WebSphere MQ V6 trial (EN)
  Бесплатная загрузка WebSphere MQ V6. Включает ограниченную интерактивную поддержку по установке на Windows® и Linux®, бесплатную в течение пробного периода.(EN)
  
  
• Информационный центр WebSphere MQ V6
  Единый, основанный на Eclipse Web-портал для всей документации по WebSphere MQ V6 с концепциями, задачами и справочной информацией по установке, настройке и использованию среды.(EN)
  
  
• Библиотека документации по WebSphere MQ
  Руководства по продукту WebSphere MQ.(EN)
  
  
• WebSphere MQ SupportPacs
  Загружаемый код, документация и отчеты по производительности для семейства продуктов WebSphere MQ.(EN)
  
  
• Общественные новостные группы WebSphere MQ
  Не IBM форум, на котором вы можете получить ответы на технические вопросы по WebSphere MQ и поделиться знаниями с другими пользователями.(EN)
  
  
• developerWorks WebSphere Business Integration zone(EN)
  Предоставляет разработчикам доступ к статьям WebSphere Business Integration how-to, загрузочным файлам, руководствам, обучающим материалам, информации по продукту и многому другому.
  
  
• Страница продукта WebSphere Business Integration
  Предоставляет техническим и бизнес-пользователям удобный обзор всех продуктов WebSphere Business Integration.(EN)
  
  
• Форумы WebSphere
  Форумы, на которых можно получить ответы на технические вопросы и поделиться опытом с другими пользователями WebSphere.(EN)
  
  
• Самые популярные загрузочные файлы WebSphere trial
  Бесплатная загрузка ключевых пробных продуктов WebSphere.(EN)
  
  
• Пробная загрузка продуктов IBM
  Бесплатная загрузка продуктов IBM® DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)
  
  
• Технические книги от IBM Press
  Удобный интерактивный заказ через Barnes & Noble.
  
  
• Технические события и web-трансляции developerWorks
  Бесплатные технические сессии от экспертов IBM, которые могут ускорить обучение и помочь в разработке наиболее сложных проектов программного обеспечения. От одночасовых Web-трансляций до круглосуточных живых сессий в городах по всему миру.(EN)
  

Об авторе

		Пол Тизеридж (Paul Titheridge) пришел в IBM в сентябре 1995 после учебы в Exeter University. Поработав в отделе Voice and Business Integration, он перешел в WebSphere and Java Messaging Support, где решает проблемы пользователей, использующих WebSphere MQ и WebSphere Application Server.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало