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

Question

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

Есть ли легкое решение для этого?

Answer 1

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

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

Answer 2

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

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

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

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

org.springframework.scheduling.quartz.SchedulerFactoryBean # 0_Worker-7 org.apache.axis2.deployment.util.Utils. [CreateClassLoader] (860) - java.io.FileNotFoundException: /tmp/axis2-tmp-9161756920591296931.tmp /axis21477916618765108874addressing-1.6.0.mar (Слишком много открытых файлов)

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

Answer 3

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

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

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

Answer 4

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

---

На самом деле, эти файлы будут развернуты в папку временных создаются каждый контекст конфигурации AXIS времени. Кроме того, похоже, что созданный Stub может принимать существующий объект конфигурации через конструктор. Итак, следующая конфигурация 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 5

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

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

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

   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

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

private static ConfigurationContext configContext; 

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

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

Если вы не передадите контекст, ось 2 создаст новый контекст для каждого вызова.

Answer 7

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

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