Как запретить Apache CXF преобразовывать примитивы в типы объектов?

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

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

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

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

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


person Jason Braucht    schedule 07.06.2009    source источник


Ответы (2)


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

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

person Daniel Kulp    schedule 08.06.2009

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

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

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

person skaffman    schedule 07.06.2009
comment
Я согласен, что JVM значительно улучшилась, однако создание ненужных объектов по-прежнему не бесплатно. По крайней мере, я хотел бы исключить это как причину снижения производительности, которое я наблюдал. Возможно, CXF не был разработан для такого использования, что вполне приемлемо. Я просто надеялся, что кто-то с большим знанием CXF взвесит эту тему, прежде чем я исключаю ее использование. - person Jason Braucht; 08.06.2009
comment
Это не бесплатно, но не за горами. JVM создаст эти новые объекты в первый раз, когда они потребуются, а затем переработает их по мере необходимости. Если вы хотите исключить это как причину, попробуйте выполнить вызов несколько раз и посмотрите, одинаково ли затрачивается время каждый раз или ситуация улучшается. - person skaffman; 08.06.2009