Как удалить Apache оси TMP файлы без перезагрузки

Question

Мы используем ось Apache для общения с веб-сервисом.Это работает нормально, но в течение дня мы генерируем 1 ГБ временных файлов.Эти файлы удаляются, если мы перезапускаем службу, но необходимость перезапуска службы каждый день, чтобы у нас не было свободного места на диске, кажется немного глупой.

Answer 1

Мы нашли программный способ избежать генерации этих файлов, что звучит как лучший способ ведения домашнего хозяйства.Я опубликовал это в комментариях из AXIS2-3919 , но скопирую его здесь на всякий случай:

---

На самом деле файлы развернуты ввременная папка каждый раз, когда создается контекст конфигурации AXIS.Кроме того, создается впечатление, что сгенерированная заглушка может принимать существующий объект конфигурации через конструктор.Итак, следующая конфигурация Spring помогла нам решить проблему (неактуальные имена бинов и классов отброшены):

<bean id="....Stub" factory-bean="...." factory-method="...." scope="request">
    <!-- this next element effects the proxying of the surrounding bean, 
        needed because .... will try to set the stub out of request scope -->
    <aop:scoped-proxy/>
    <constructor-arg index="0" >
        <!-- The WS stub is created here, and passed to the factory-method of ... as a parameter -->
        <bean class="com......ws.....Stub" scope="prototype">
            <constructor-arg ref="axisConfigContext" />
        </bean>
    </constructor-arg>
</bean>

<!-- Exists to avoid deployment of axis jar into temp dir for each request. See     AXIS2-3919 for more details. -->
<bean id="axisConfigContext" 
        class="org.apache.axis2.context.ConfigurationContextFactory" 
        factory-method="createConfigurationContextFromFileSystem">
    <constructor-arg index="0"><null /></constructor-arg>
    <constructor-arg index="1"><null /></constructor-arg>
</bean>

Answer 2

Временные файлы создаются всякий раз, когда создается новый ConfigurationContext.Поэтому создайте ConfigurationContext только один раз в статическом блоке и используйте его во всех последующих вызовах.

private static ConfigurationContext configContext;

static {
     configContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem(null, null);
}

public callService() {
    Stub stub = new Stub(configContext, END_POINT_URL);
    //code
}

Если вы не передадите контекст, axis2 будет создавать новый контекст при каждом вызове.

Answer 3

Я попробовал решение (предоставленное гордым человеком) создания статического блока, и оно прекрасно работает. Он создает только временные файлы для первого запроса. Я также обновляю uilimit на сервере Linux до 16000. Теперь мне не нужно удалять временные файлы.

private static ConfigurationContext configContext; 
static{   
   configContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem(null, null);  
}

Answer 4

Я смотрел на ту же проблему, и похоже, что она может быть исправлена ​​в версии 1.7.0:

https://issues.apache.org/jira/browse/AXIS2-3919

Я еще не пробовал, но я обновлю этот комментарий, как только сделаю.

Answer 5

Я столкнулся с этой проблемой в последнее время, и это для нас остановка шоу. У меня есть пара решений:

1. установить для java.io.tmpdir каталог, который не существует. Это может привести к нежелательным последствиям!

2. Создайте сделанную на заказ версию org.apache.axis2.deployment.util.Utils и отредактируйте функцию createClassLoader. Разверните его в пути к классам перед библиотекой осей. Эта функция принимает логическое значение extractJars, которое вызывает копирование файла, если это невозможно (например, если каталог tmp не существует), тогда загрузчик классов отработает исходную копию файла jar. Снова могут быть некоторые нежелательные последствия для этого. Существует несколько вариантов этой темы, я также рассмотрел добавление некоторого кода, чтобы создать только одну копию банки, но я думаю, что это решение лучше, поскольку оно использует существующую функциональность. Вот моя версия функции:

   public static ClassLoader createClassLoader (URL[] urls,
                                       ClassLoader serviceClassLoader,
                                       boolean extractJars,
                                       File tmpDir,
                                       boolean  isChildFirstClassLoading) {
   List embedded_jars = Utils.findLibJars(urls[0]);
   return createDeploymentClassLoader(urls, serviceClassLoader,
                                  embedded_jars, isChildFirstClassLoading);
   }
   

Надеюсь, это поможет.

Answer 6

Я не могу найти другого выхода, кроме как перезапускать каждый день. Если вы не остановите процесс, он не позволит удалить файлы tmp. Я изменил системное свойство "java.io.tmpdir" на другое место с большим дисковым пространством, чтобы по крайней мере на нем не заканчивалось дисковое пространство.

System.setProperty("java.io.tmpdir","/opt/Axis2Temp"); 

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

org.springframework.scheduling.quartz.SchedulerFactoryBean # 0_Worker-7 org.apache.axis2.deployment.util.Utils. [CreateClassLoader] (856) - исключение, извлекающее файлы jar во временную директорию: java.io.FileNotFoundmpception / t /axis2-tmp-9161756920591296931.tmp/axis21477916618765108874addressing-1.6.0.mar (слишком много открытых файлов): переключение на механизм загрузки альтернативного класса

org.springframework. tmp / axis21477916618765108874addressing-1.6.0.mar (слишком много открытых файлов)

Чтобы решить эту проблему, я увеличил ulimit для открытых файлов до 4000.

Answer 7

Если вы знаете путь к временному каталогу, вы можете запускать rm -rf / path / to / temp / * каждые 6, 12 и т. Д. Через cron.

напишите bashscript о том, что вы работаете в системе linux, чтобы очистить этот каталог, если он достигнет определенного размера.И положить его также в crontab.