Community
Participate
Working Groups
Build Identifier: 20110615-0604 I have to force closed the Eclipse IDE when it hangs. Typically I am editing. When the Automatic Content assist kicks in (i.e. typing a '.' (dot) after a variable in the editor). This does not happen all the time. Reproducible: Sometimes Steps to Reproduce: 1. while editing a clase, type a class variable followed by a '.' (dot). 2. 3.
Created attachment 203813 [details] thread dump
java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
Goes into JDT code and then to something else and then back into JDT code, not sure whose at fault here.
The thread dump doesn't seem to show a deadlock, so I assume Eclipse was just terribly busy and therefor didn't answer within expected time. From JDT side I don't see how we could've caused that but I wonder whether the jpt.jaxb code might be doing a bit too much work here: during content assist (which must be fast) it looks like a call to GenericJaxbProjectManager.buildJaxbProjects() might be too heavy. Calling back into JDT to create an AST is OK for one file or two, but if this is done for each file in each JaxbProject than this could well be the cause for a perceived "hang", no? @Tom: seeing a call GenericJaxbProjectManager.start() in the stack I wonder whether this occurs only while Eclipse isn't fully initialized? Can you somehow provoke the jaxb support to initialize before you start normal work? Maybe it's just the first time initialization that's so slow? Passing on to Dali JPA Tools for further comments.
The JPT build only happens one time (or should) - the first time our code is invoked. Is this happening every time?
I would guess as a workaround that auto activation could be disabled until we can fix the root issue (in Dali) in Indigo SR2. My understanding is that there is a built in time-out on user activated content assist that JDT enforces, but in this case, since it is auto, perhaps this is not enforced?
(In reply to comment #4) > The thread dump doesn't seem to show a deadlock, so I assume Eclipse > was just terribly busy and therefor didn't answer within expected time. > > From JDT side I don't see how we could've caused that but I wonder > whether the jpt.jaxb code might be doing a bit too much work here: > during content assist (which must be fast) it looks like a call to > GenericJaxbProjectManager.buildJaxbProjects() might be too heavy. > > Calling back into JDT to create an AST is OK for one file or two, > but if this is done for each file in each JaxbProject than this could > well be the cause for a perceived "hang", no? > > @Tom: seeing a call GenericJaxbProjectManager.start() in the stack > I wonder whether this occurs only while Eclipse isn't fully initialized? > Can you somehow provoke the jaxb support to initialize before you start > normal work? Maybe it's just the first time initialization that's so slow? > > Passing on to Dali JPA Tools for further comments. I am using JAXB extensively in my current project. I have hundreds of classes generated by xjc; is that too many? I have since noticed that if I wait long enough the hang ends and I can continue working. The times involved are too long though - it's unworkable (10's of minutes). How can I provoke jaxb support to initialise before starting work? I'd like to try that out to see if there is any change to the hanging condition.
(In reply to comment #7) > (In reply to comment #4) > I am using JAXB extensively in my current project. I have hundreds of classes > generated by xjc; is that too many? I have since noticed that if I wait long > enough the hang ends and I can continue working. The times involved are too > long though - it's unworkable (10's of minutes). Certainly not too many classes. We have test projects that are larger. My guess is that there is a bug in our code that is being exposed by something "interesting" in your model. It would be great if you could put a test case together that could reproduce the problem, but I'm guessing that may be difficult. If you could capture another thread dump that may help isolate what the problem could be. Another question, do you have a large number of jars or very large jars on the project build path? This can cause long project initialization times. > > How can I provoke jaxb support to initialise before starting work? I'd like to > try that out to see if there is any change to the hanging condition. My guess is that this will not change the long project build time. That said, you could browse the JAXB Content in the Project Explorer view or Validate the project to start the build process. It would be a good test to make sure we are thinking in the right direction.
Firstly, apologies for the long time between comments - I have been off sick. I have found what I think may have been the cause of the glitch. In the Project Properties->JAXB->Schemas I had added a JAXB Schema for Validation and Content Assist. The schema file was only a test file which I later removed from the filesystem but not the reference to it in the Project Properties settings. I've cleaned up the Project Properties and now Content Assist works again without hanging. Would it not be better to have a warning or error message in the case the schema file intended for Validation and Content Assist were missing?
Absolutely it would. And there is some validation there already. But apparently the schema you've specified falls between the cracks somehow. It seems that there is some large delay in trying to load it. Can you go into a bit more detail about the nature of the schema? Was it a local file that no longer exists? Workspace file? Local catalog? It shouldn't take so long to access something that doesn't exist.
(In reply to comment #10) > Absolutely it would. And there is some validation there already. > > But apparently the schema you've specified falls between the cracks somehow. > It seems that there is some large delay in trying to load it. Can you go into > a bit more detail about the nature of the schema? Was it a local file that no > longer exists? Workspace file? Local catalog? It shouldn't take so long to > access something that doesn't exist. The schema was a custom schema. It was a local file that I eventually decided I didn't need and so deleted it, forgetting I had added the reference in the Project Properties. Trying to recreate the issue, I have failed so far to make Eclipse hang.
Downgrading severity on this since we discovered likely cause, and workaround was available. We still need to investigate and see if we can reproduce and fix this issue.
