Как удержать Apache CXF от преобразования примитивов в объектные типы?

Question

Я оцениваю Apache CXF для проекта, поэтому написал небольшое демонстрационное приложение, чтобы опробовать некоторые вещи.Следуя руководству пользователя CXF, я смог довольно быстро запустить свое приложение.

Одна вещь, которую я хотел проверить, заключалась в том, насколько хорошо CXF способен обрабатывать метод, который возвращает большой массив примитивов.Итак, я определил метод 'float[] getRandFloats(int count)' который просто возвращает массив указанной длины, заполненный случайными числами.Глядя на WSDL, сгенерированный java2wsdl, Я вижу , что метод правильно указывает возвращаемый тип float[].Проверяя клиентскую часть, я также вижу, что я (в конечном счете) получаю float[].

Я заметил, что по мере увеличения количества элементов в моем массиве снижается производительность клиента.Я запустил профилировщик на стороне клиента и увидел, что существуют Float объекты, создаваемые для каждого элемента в возвращаемом массиве.Кажется, это происходит, когда CXF вызывает JAXB во время синтаксического анализа ответа.

Я оцениваю CXF для использования с приложением, которое потенциально отправляет обратно миллионы чисел с плавающей запятой, поэтому создание этого объекта крайне нежелательно.Чтобы использовать CXF, мне нужно было бы найти способ предотвратить создание этого объекта.Я просмотрел документацию и список рассылки, но не нашел способа обойти это.

Кто-нибудь сталкивался с подобной проблемой при использовании CXF?Если да, то как вам удалось обойти это?

Answer 1

Это определенно не то, с чем CXF может что-либо поделать.Это скорее проблема JAXB.Я полагаю, что внутренне JAXB обрабатывает все случаи "maxOccurs != 1" как коллекцию java, а не массив.Он просто преобразуется в массив на последнем шаге процесса, если это необходимо.Поскольку коллекции Java не могут содержать примитивы, в них будут храниться объекты с плавающей точкой.

В любом случае, это нужно было бы обсудить с ребятами из JAXB.:-(

Answer 2

Вы говорите, что производительность cliernt снижается по мере увеличения количества элементов в массиве.Для меня это звучит разумно - больше данных, меньше производительности.Чего вы там ожидали?Пока это линейная градация, она ведет себя нормально.

Что касается создания миллионов объектов, современная JVM сделает это, не потея.Я подозреваю, что дизайнеры CXF хорошо осведомлены об этом.У старых JVM были плохие алгоритмы GC, и то, что миллионы объектов перемещались, действительно вызывало проблему, но это больше не так, особенно с такими недолговечными объектами, как у вас здесь.

Итак, с одной стороны, мы имеем снижение производительности, вызванное большим количеством данных и тем фактом, что создаются миллионы объектов.Однако нет никаких доказательств того, что эти два наблюдения связаны.