#323 Xinsff API dont start with Tomcat

2.2 (final)
closed-fixed
5
2009-12-07
2009-10-23
No

Any of our xinsff API won't start using xins 2.2 and Tomcat 5.5.25, though they do run using the command: xins run-<API>. I attached the log file.
The APIs that don't use the xins front end calling convention have no problems as well.

Discussion

  • Anthony Goubard

    Anthony Goubard - 2009-10-27
    • assigned_to: nobody --> agoubard
     
  • Anthony Goubard

    Anthony Goubard - 2009-10-28

    Having done some investigation it seems to be a bug in Tomcat.
    Tomcat calls Servlet.init() twice where the specification say "Note that init() will only be called once; it will not be called again unless the servlet has been unloaded and then reloaded by the server."
    http://java.sun.com/developer/onlineTraining/Servlets/Fundamentals/servlets.html#lifeCycle

    Here Tomcat call the method twice: when starting and with the first request.

    Note that happens as the Servlet is org.xins.server.APIServletSingleThreaded
    If the Servlet is org.xins.server.APIServlet (used for other cc) the problem doesn't occur.

    My suggestion is to do a small Servlet that reproduce this case and submit this bug in Tomcat bug database.

    Note that I used Tomcat 5.5.28.

     
  • janwillemb

    janwillemb - 2009-11-24

    Please note that the submitted bug has been closed with the status worksforme.

     
  • Anthony Goubard

    Anthony Goubard - 2009-11-28

    I saw it too but I disagree that creating 2 servlet instance is normal when starting the servlet container.
    What happen for example if your servlet write in a file?

    In our case it fails because the api is created using apiClass.getDeclaredField("SINGLETON"); which is static so both instance of the servlet will receive the same object. So when the second servlet try to bootstrap the api the object is in a incorrect state.

     
  • Anthony Goubard

    Anthony Goubard - 2009-11-28

    I've read the SingleThreadModel specs and indeed it's allowed in this case to create multiple instances. Note that the class is also deprecated.

    The real solution would be to get rid of ThreadLocal in xinsff and remove the SingleThreadModel.

     
  • Anthony Goubard

    Anthony Goubard - 2009-12-07

    Fixed. will be in xins 2.3 alpha 3.
    I don't use the SingleThreadModel class anymore.
    I've replace the ThreadLocal of xins ff with a hashtable using the Log4j NDC as key.
    The thing I don't have is a test to test the behaviour of xins ff in concurent mode, especially that one client doesn't accidently steal the session of another user.

     
  • Anthony Goubard

    Anthony Goubard - 2009-12-07
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks