Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Spring-DM with Jetty on Equinox leaves temporary files around after shutdown Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring-DM with Jetty on Equinox leaves temporary files around after shutdown

    Hi Spring wizards,

    I have a mysterious issue with leftover temporary files. I am running 2 webapps with Spring DM 1.1.2, Spring Framework 2.5.6, Jetty 6.1.9 on top of Equinox (Ganymede). To debug, I run Equinox with an Eclipse launcher; the deployed software is using a slightly modified version of Apache Commons Daemon to run as a Windows Service. This all works very well together.

    However, I have one mysterious problem. When I shut down Equinox ("close" from the console in debug, through the service hooks on production systems), a copy of each of the webapps gets left behind in the appropriate temporary directory (%WINDIR/Temp for the service, or Local Settings/Temp in my user directory for debugging). The filenames look something like this:
    jetty-server8039181279835132267.osgi

    The tail end of my log file says:

    Code:
    2009-06-29 19:49:00,590 Thread-0 INFO  Application                     - Application is closing
    2009-06-29 19:49:00,590 Thread-24 INFO  ContextLoaderListener           - Stopping [org.springframework.bundle.osgi.extender] bundle v.[1.1.2]
    2009-06-29 19:49:00,590 Thread-24 INFO  TimerTaskExecutor               - Cancelling Timer
    2009-06-29 19:49:00,600 Thread-24 INFO  TimerTaskExecutor               - Cancelling Timer
    2009-06-29 19:49:00,610 Thread-24 INFO  sgiBundleXmlApplicationContext  - Application Context service already unpublished
    2009-06-29 19:49:00,610 Thread-24 INFO  sgiBundleXmlApplicationContext  - Closing org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext@6779e6: display name [OsgiBundleXmlApplicationContext(bundle=org.springframework.bundle.osgi.web.extender, config=bundleentry://53/META-INF/spring/extender/jetty-deployer.xml)]; startup date [Mon Jun 29 19:32:37 PDT 2009]; root of context hierarchy
    2009-06-29 19:49:00,610 Thread-24 INFO  DefaultListableBeanFactory      - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@6f8b2b: defining beans [warDeployer]; root of factory hierarchy
    2009-06-29 19:49:00,610 Thread-24 INFO  Activator                       - Goodbye World!!
    2009-06-29 19:49:02,183 Thread-24 INFO  BundleXmlWebApplicationContext  - Unpublishing application context OSGi service for bundle Sensor firmware Plug-in (com.agilent.tentacle.sensorfirmware)
    2009-06-29 19:49:02,183 Thread-24 INFO  BundleXmlWebApplicationContext  - Closing org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext@8e7f54: display name [OsgiBundleXmlWebApplicationContext(bundle=com.agilent.tentacle.sensorfirmware, config=/WEB-INF/applicationContext.xml)]; startup date [Mon Jun 29 19:33:20 PDT 2009]; root of context hierarchy
    2009-06-29 19:49:02,183 Thread-24 INFO  DefaultListableBeanFactory      - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@5f7d3f: defining beans [firmwareService,org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean#0,userFirmwareRequestHandler]; root of factory hierarchy
    2009-06-29 19:49:02,213 Thread-24 INFO  BundleXmlWebApplicationContext  - Unpublishing application context OSGi service for bundle Portal (com.agilent.tentacle.sms.core;singleton:=true)
    2009-06-29 19:49:02,213 Thread-24 INFO  BundleXmlWebApplicationContext  - Closing org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext@1b7bf86: display name [WebApplicationContext for namespace 'springDispatcher-servlet']; startup date [Mon Jun 29 19:33:05 PDT 2009]; parent: org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext@14b2f1a
    2009-06-29 19:49:02,223 Thread-24 INFO  DefaultListableBeanFactory      - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1e5c339: defining beans [/coreServiceHttpInvoker,/sensorConfigServiceHttpInvoker,/smsConfigServiceHttpInvoker,org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean#0,/tdoaServiceHttpInvoker,/retaskerServiceHttpInvoker]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@48bc64
    2009-06-29 19:49:02,223 Thread-24 INFO  BundleXmlWebApplicationContext  - Unpublishing application context OSGi service for bundle Portal (com.agilent.tentacle.sms.core;singleton:=true)
    2009-06-29 19:49:02,223 Thread-24 INFO  BundleXmlWebApplicationContext  - Closing org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext@14b2f1a: display name [OsgiBundleXmlWebApplicationContext(bundle=com.agilent.tentacle.sms.core, config=/WEB-INF/applicationContext.xml)]; startup date [Mon Jun 29 19:32:57 PDT 2009]; root of context hierarchy
    2009-06-29 19:49:02,223 Thread-24 INFO  DefaultListableBeanFactory      - Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@48bc64: defining beans [start1451Bean,netIfResolver,mapService,org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean#0,sensorTracker,clientBlock,org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean#0,sensorConfigurer,executor,connPool,databaseManager,org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean#1,org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean#1,resourceManager,multicastProcessor,dmcCsCoder,httpTransport,messageHandler,statusProcessor,tdoaWaveProcessor,cfgMgrMessageProcesor,dolphinMessageProcessor,watchdogMessageProcessor,appmgrMessageProcessor,dmcAdapter,org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean#2,rpcRequestHandlerServlet,licenseHandler]; root of factory hierarchy
    2009-06-29 19:49:02,233 Thread-24 INFO  ClientBlock                     - ClientBlock was asked to shut down.
    2009-06-29 19:49:02,233 Thread-24 INFO  ClientBlock                     - Sending shutdown command to Executor
    2009-06-29 19:49:02,233 TentacleExecutor INFO  Executor                        - Shutdown received - Closing down executor thread.
    2009-06-29 19:49:02,243 TentacleExecutor WARN  Executor                        - Executor is terminating.
    2009-06-29 19:49:02,243 SensorEventDispatcher INFO  SensorTracker                   - Interrupted
    2009-06-29 19:49:02,243 SensorEventDispatcher INFO  SensorTracker                   - SensorEventDispatcher terminated.
    2009-06-29 19:49:02,243 Thread-24 INFO  DatabaseManager                 - Closing all database connections
    2009-06-29 19:49:03,074 Thread-24 INFO  HsqldbDatabaseManager           - Sending Shutdown command to HSQLDB
    Has anybody seen this before? I don't really know where to even start looking (so far I have considered the WebExtender, well, "magic").

    Thank you for any insights,

    Jan Schiefer

  • #2
    Those are unpacked war bundles. similar to work directory in tomcat.
    I had similar problem, only such temp jetty directories were placed in {current user} /temp. You have to set -Djava.io.tmpdir="path_to_temp_directory" parameter if you need to change it. After each redeploy of web bundle jetty creates new directory.
    Check jetty FAQ http://jetty.mortbay.org/jetty5/faq/...10tempdir.html
    Last edited by mccat; Jun 30th, 2009, 01:27 AM.

    Comment


    • #3
      mccat is right - the temporary files are created either by the container, either by Spring DM web container for deploying the bundles. Unfortunately, even though we mark the files as deleteOnExit, this doesn't seem to work all the time on windows.
      It depends on various factors - on my machine things get cleaned up though users reported the files are still left on the drive.

      Feel free to raise an issue if this is a problem for you.

      Comment

      Working...
      X