BUG: NullPointerException sometimes occurs when copying files

This topic contains 9 replies, has 2 voices, and was last updated by  Jozef_jb 6 months, 1 week ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #544731 Reply

    Jozef_jb
    Participant

    See attached file. I get this NullPointerException frequently. What I’m doing is saving a file, and it’s supposed to copy that file to my Tomcat deployment. Instead I get this vague NullPointerException without a stack trace, and I have to save the file again.

    That’d be fine if it occurred once a day. But when I’m messing with stylesheets, I’m saving frequently and Alt-Tabbing to the browser to check my work. I want to be able to rely on MyEclipse to copy the file, and if it did not work, to try again for a bit before giving up with a coherent error message.

    Attachments:
    You must be logged in to view attached files.
    #544734 Reply

    Brian Fernandes
    Moderator

    Jozef,

    I’m hoping there’s there’s more in the Error log (perhaps another error that’s reported at the same time).

    1) Can you send us the entire error log?
    2) Are you now on CI 8 or CI 9? Is this something new, or has it always been happening?
    3) A screenshot of the Tomcat Configuration editor would help.
    4) After the error, what do you see in the Servers view against the Tomcat server’s status?

    Apologies for the frustrating experience.

    #544735 Reply

    Jozef_jb
    Participant

    No need to apologize, I’ll cope with it. I would like to see if I can help to get these issues fixed in upcoming releases though.

    1) I think I have found something useful. See attached file. I think it’s the stack trace that leads to the NPE.

    2) This is on CI 8. This has been happening for a while now. If I had to guess it would be ever since the new Servers tab was introduced. I hope the attached stacktrace can fix the issue.

    3) Alright. “scrn4.png” shows our configuration. I think the culprit may be the publishing interval, which is set to 0 seconds because, and I cannot stress this enough, all we need MyEclipse to do is copy the files from A->B. We have configured everything else in such a way that (My)Eclipse will write its own configuration files to the local workspace. “scrn5.png” shows a change to the launch configuration (accessed via the “Open launch configuration” link on the configuration page) which prevents (My)Eclipse from using its own configuration.

    4) The status is stuck on “Publishing…” until I republish (or trigger a republish by saving a file). Then it will publish correctly and the status goes back to “Synchronized”.

    Attachments:
    You must be logged in to view attached files.
    #544886 Reply

    Brian Fernandes
    Moderator

    Jozef,

    Thank you for the log, that helps. Now we did try to reproduce with settings similar to yours (including the 0 second publish interval), but even with “frantic saving”, we couldn’t get it to break.

    1) Could you tell me more about the structure of your project? Is it a simple, standalone Web project? Or does it depend on a few other projects in your workspace? I ask because the stack trace references child modules. If yes – what projects are these? A screenshot of your Deployment Assembly property page might help (but is not necessary at this point).

    2) When the error occurs, do you think you might be saving multiple files at the same time? Or, could you be saving a file, making a modification and then saving again within a couple of seconds?

    #544909 Reply

    Jozef_jb
    Participant

    1) Attached is the “.settings” folder, “.classpath” and “.project” file of the project.

    The project is a Web Project. Note that this is also a Maven Project, as this is forced on us due to another issue.

    It would not surprise me if the project being a Maven Project causes it to resolve dependencies on the workspace. We try to turn this off by using the “Disable workspace resolution” option. Unfortunately, due to the opt-out nature of this option this is not always configured correctly. I have confirmed that at least one project in my web deployment was resolving projects from the workspace. This project is completely unrelated to the project I was working on though, so I don’t see how that would cause the NPE.

    2) I am saving one file called “style.less”. This file is meant to be copied from “F:\Workspaces\Git\project\WebRoot\css\style.less” -> “C:\development\Tomcat\apache-tomcat-7.0.59\webapps\project\css\style.less”

    The compilation of less to css is handled by a servlet which does not modify the source file nor any other files in the “webapps” folder.

    It occurs to me that the servlet may still be reading the “style.less” file (which may result in a file lock) while the file is being copied to the Tomcat deployment.

    Attachments:
    You must be logged in to view attached files.
    #545013 Reply

    Brian Fernandes
    Moderator

    Jozef,

    We still couldn’t reproduce with your project set up – though that isn’t too surprising. I will admit that we haven’t yet had a deep tech dive into the code yet, but as you pointed out, the problem may be caused by our inability to write to the file in the destination due to the fact that the servlet is still reading it. If you are able to reproduce this reliably, could we test this theory by turning the converter off for a bit while you edit the file as you normally would? (of course your CSS will remain stale)

    Is the log that you see accompanied by an error dialog? Or is it just an error logged? If it’s just the latter, and our assumption that the error was caused by a failure to write the file, an improvement we could make is a better log message – but not sure what else we could do as the lock is out of our hands. What are your thoughts?

    #545053 Reply

    Jozef_jb
    Participant

    I’ll try and see if I can confirm that the error is caused by our resource servlet. I think the best way to do that is to save other types of files (that the resource servlet doesn’t touch) frequently and seeing if the same problem occurs.

    The log is accompanied by an error dialog that I have to dismiss every time this occurs.

    My thoughts on this is that (My)Eclipse should retry writing the file a couple of times if any exception occurs. Even a single retry may be enough to fix the problem entirely. If there is a slight delay between attempts, say 250ms between the 1st and 2nd attempt, incrementing by a factor of 2 for each attempt up to a maximum of 4? You’d have at most a 7.8 second delay before the final error message is thrown.

    #545065 Reply

    Brian Fernandes
    Moderator

    Jozef,

    Yes, saving other types would work to prove it’s the servlet. Not knowing how the servlet works, I guess it periodically just checks the file, and you’d hit the problem if it was checking when you saved a change? In this case, changing the publish interval to 1 (from 0) wouldn’t help – but if you only see the errors if you make subsequent quick saves (is this the case?) then maybe a delay might help mitigate the problem (by the time we try to push the new change, the servlet has finished reading the previous one).

    Clear on the error dialog – that is something we can look at.

    On retrying – I did think of that; it will have to be carefully designed of course. This is also not a very common use case – content can certainly be locked, but in our experience, it typically remains locked until something more drastic is done (like shutting down the server).

    #547327 Reply

    Brian Fernandes
    Moderator

    Jozef,

    I’ll try and see if I can confirm that the error is caused by our resource servlet. I think the best way to do that is to save other types of files (that the resource servlet doesn’t touch)
    frequently and seeing if the same problem occurs.

    Did you happen to try this – was the problem only reproducible with files managed by the servlet?

    #547331 Reply

    Jozef_jb
    Participant

    The problem occurs even when the servlet is not managing the file. (I actually had to restart MyEclipse earlier this morning because of consistent NPE’s when trying to publish. The Tomcat server wasn’t running.)

Viewing 10 posts - 1 through 10 (of 10 total)
Reply To: BUG: NullPointerException sometimes occurs when copying files