This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
From the documents provided on debugger rewrite I've got a feeling that a big challenge is incorporation of effective model of communication from the UI to the API and then to various debugger pluggins that can have different characteristics (be fast, be slow, etc.). The two goals should be: good performance of UI and testability (no asynch behaviour). I am very interested in knowing the approach the debugger team is going to take to solve these goals.
Sample problem: I have a variable reference and I want to get list of its fields. The UI just asks for the value, but then it should go on and to handle other user requests and repaint as soon as the value is computed, meanwhile it can just display "computing". However in any other kind of situations (build-in expression evaluator, writing tests, logging to log file) there is no reason in continuing the computation without knowing the actual variable value. Sidenode: Incorporation of these two requirements should be a strong reason for sepration of API and SPI - API can handle both methods (as they are convertible between each other) and there can be two SPIs - one for asynchronous and one for synchronous evalations. The possible solutions may include some kind of "future value" http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html or having a special "request-event thread" for SPI and making all API calls switch there and compute what they need in single thread mode, while API allowing calling getValue() or computeValue (HolderForResult), etc. What ever solution is choosen is fine, it just is not ok to close our eyes and say that this will be solved later. It will not. If the API does not support lazy concepts since begining, it will not be able to absorb them in future.
Thanks for valuable comment Yardo. I like solution with two versions of Service Provider. We should look on: VariablesProduces.getVariables () ThreadsProducer.getThreads () CallStackProducer.getCallStack () and all Filters.
BTW: There is similair issue on debugger API for a long time: http://www.netbeans.org/issues/show_bug.cgi?id=34335
Uh-oh. I've been advocating the exact opposite. We have used a totally _async_ model between dbx and the gui and have had no end of trouble of the strict sync model imposed by debuggercore I understand that within the current flavor of debuggercore architecture, where the models in the gui are _the_ models sync makes sense. But thats not true for all use cases That's why I drew the asciigram here http://www.netbeans.org/servlets/ReadMsg?msgId=623352&listName=nbdev I had in mind a separation of engine where calls are synhronous and "ui" where calls are async, with updates as callbacks to the UI. Having the UI post async, fire-and-forget messages is a must in the new "everything on the AWT-EQ" model.
I do not understand your response, Ivan. I agree that support for async model is requirement on new Debugger API. And I would like to solve it. Yarda has suggested one possibility how to fix this problem. You do not agree with Yarda's solution? Do you think that it will not work?
Here is an excerpt from the conversation I have with Ivan. I hope it will clear things up. Y: Just to clarify and describe how I understand: Y: "totally _async_ model between dbx" means that you send a request Y: (using Y: a telnet, probably) to watch value of variable A. Then you do some Y: debugging (step, next, etc.) and whenever the variable A changes Y: you Y: receive a message (in case of telnet something is printed on the Y: output) Y: with new value. Y: Y: "strict sync model" refers to a problem when UI sets a breakpoint Y: to be Y: enabled, immediatelly changes the internal structures and then Y: notifies Y: dbx about it. However dbx may not be capable to handle the request Y: and Y: this results in IDE thinking breakpoint is disabled and dbx still Y: having Y: it enabled. I: Yes, this _is_ more or less correct. And thanks for paraphrasing. Y: Another set of clarifications and explainations: Y: Y: "ui where calls are async" - ui calls turnBreakpointOff() but does Y: not Y: wait for the result, gets notified via a callback/listener/event Y: breakpointStateChanged(now_it_is_off) later. Meanwhile UI can show Y: "requested change". Y: Y: Yarda's async ui example - ui needs to know the list of fields of Y: an Y: object. It cannot call variable.getFields() but should do Y: variable.computeFields() and wait for a callback saying Y: fieldsComputed(here_are_the_fields). Y: Y: Yarda's async ui example 2 - ui needs to know the value of a Y: variable. Y: It cannot just call variable.getValue() but should do Y: variable.computeValue and wait for the callback saying Y: variableValue(isSomething). Y: I have a feeling that my understanding of your complaints, plus my Y: two Y: examples make sence together to say that "Having the UI post async, Y: fire-and-forget messages is a must". I: Ok, this is a good start and direction. I: Can you repost your response on nbdev? Let's discuss on nbdev, but as this seems to be settled a bit, I am making this TCR for any future debugger API implementation.
Planned for Promo D
*** Issue 34335 has been marked as a duplicate of this issue. ***
Turning into real TCR, waiting for debugger team to evaluate.
Fixed. Breakpoints supports fast & slow model. Watches supports fast & slow model. And content of all debugger views supports fast & slow model. If you will find some place, where the slow model is not supported, feel free to fire a task fo me & debugger.
Jardo, could You please verify this issue?
We're _almost_ out of the woods here wrt debuggercore. Mostly because the modelview package provides a way to completely customize actions and property editing. But there are still some corner cases, like 50761 for example. Also not everythng seems to be customizable via moelview. Breakpoints and Watches are global and managed by debuggercore and their 'enable/disable' pareadigm isn't asynchronous.
Ivan, can you verify or reopen the issue? It is up to you. My own knowledge is that in 4.0 timeframe this issue was not implemented at all, and jjancura just closed it with hope nobody will notice. However I also know that in 4.1 there were changes that replanned everything into RequestProcessor. Thus the behaviour is supposed to be asynchronous by default. But I cannot confirm the quality of the impl, I just know there was some kind of work on that. Ivan, you are the user of the API, so please verify or reopen.
Too many things .... (1) jjancura claims that "* supports fast & slow model" but doesn't say how, so there's no way to precisely verify that statment. (2) We seem to be talking about two distinct scenarios. a) results of actions b) lengthy "pull"s of data. Yarda suggested something like promises for the lengthy pull of data. My concern is mainly with actions and setting of properties. (3) Yardas noted that "in 4.1 there were changes that replanned everything into RequestProcessor". Did this really happen? I had noticed a PB with this, complained about it and I think saw it get reverted but lost track. I had thought that it was established that RP was "evil". Maybe it's in 4.2 now which I'm not in position to track? That would cause lots of trouble for me.
Re.3: See http://www.netbeans.org/download/4_1/javadoc/ViewModel/apichanges.html#issue-53073 which is linked from http://www.netbeans.org/download/4_1/javadoc/apichanges.html
The debugger actions are now replanned into RequestProcessor. Therefore all actions are performed lazily now. The view model is synchronous, but can have asynchronous implementation. JPDA debugger provides variable values in an asynchronous manner (first displays "Evaluating...", after the value is retrieved from JDI, it's refreshed with the proper value. Anyone who implements the models can do the same. Therefore in my point of view this is fixed. Please elaborate on where specifically is the problem if something is not achivable in 4.2. Thanks.
(1) The fact thet debugger actions went on the RP is _regression_ and should be undone. I depend on things to come in on the AWT queue because that's how I synchronize with network messages from my debugger engine, which also come on the AWT queue. This is an incompatible API change in fact. Furthermore RP's have all kinds of problems like executing two user actions in parallel which leads to not guaranteeing the serial order of user actions. (2) When I use the terms sync and async I"m not referring to multi-threading. A plain function call is synchronous if it gets an answer immediately, or if upon return it can assume that the side-effect happenned. the first case has to do with value fetches and the second case with action side-effects. As you say the viewmodel mechanism allows for flexibility in both async value fetching and async action execution. However .... - it doesn't require actions to go on the RP to achieve this. In other words the move to RP is not a solution to this issue but a solution to some other issue. - it's interactions that are _not based on viewmodel_ that are still problematic. See my comments of Jul 11. To clarify what I mean wrt Breakpoint.enable() ... If the user clicks on the enable checkbox, PROP_ENABLED will get fired. I will send this to dbx as "handler -enable 2". Dbx will complain because of some error and actually not enable it. Yet, Breakpoint.isEnabled() will return true. True, enable() and isEnabled() are abstract and can be override w/o viewmodel, but the problem is that, I think, we need to split enable() into postEnable() (as in HTTP POST) and doEnable(), or something like that.
(1) This is not an API change. Just JPDA actions were changed to be asynchronous. You're free to implement your actions how you want. Please see issue #58057. We use one RequestProcessor with throughoutput 1, therefore the actions are processed in the given serial order, no action can run in parallel with another. (2) "When I use the terms sync and async I'm not referring to multi-threading..." Yes, but often one can achieve the asynchronous behavior via multi-threading. It's not really clear to me what all parts of the debugger are subject of this bug... If it reduces to breakpoints (I remember some discussion concerning this some time ago...), we likely need to submit a separate issue and suggest and API change... A plain function call is synchronous if it gets an answer immediately, or if upon return it can assume that the side-effect happenned. the first case has to do with value fetches and the second case with action side-effects.
(1) Sure it's an API change. The semantics of the interface have completely changed. What thread a particular call comes on is as much a part of an API as let's say which exceptions get thrown. An RP with a throuput of 1 is good. But ... It seems that this move to RP's was done as a fix for bug 58057 w/o any consideration of whether any other code might get affected. You are as free to implement the callback anyway you want to as well, so why not have JPDA serialize things on it's own? Instead I'm now in a situation where an even get called back on the AWT thread, you post it to an RP, and then I have to send it back to the EQ. Your bug fix penalizes my code. (2) I can't see how you can support a post-do model with any amount of threads if your functions don't support it. It's not just for breakpoints; I've used them as an example. Let's look at plain check boxes ... they are a view unto some boolean model. When you click it the check box _doesn't_ visually appear just some event gets dispatched (posted) ... later some code will set the checkbox (do). Now in the case of bpts is the "model" of enabledness, the boolean in debuggercore...Breakpoint? I don't think so. There is probably a breakpoint proxy object in debuggerjpda and another one in JDI, not to mention the real breakpoint in the VM. I see the debuggercore Breakpoint object as just another view _layer_ and not the final word on the value of the model. Are there cases other than bpts? It seems to me that debuggercore has decided to make certain properties be predefined. These are the ones that have predefined column-id's in Constants. In addition to predefined column-id's they typically have an explicit accessor method, presumably as a convenience. Why I'm saying is that it turns out to be inconvenient because these accessors do not support the post-do model.
(1) Well this is a consequence of the original bad design. We must not process the JPDA actions in AWT. And this was the only way to do it, if we did not want to make API changes. However, it looks like we'll have to do an API change for that to implement it correctly... I'll prepare a fast-track API change request. I'm not sure you get the change correctly, when you say "You are as free to implement the callback anyway you want to as well, so why not have JPDA serialize things on it's own? Instead I'm now in a situation where an even get called back on the AWT thread, you post it to an RP, and then I have to send it back to the EQ. Your bug fix penalizes my code." This is not true, *only* JPDA actions were changed. No semantics of the call was changed, the actions are still run on AWT. (2) So if I get it right, you want to have an asynchronous version of TableModel.setValueAt(...) method. You can achieve that by a smart implementation of set/getValue. I'll do that in BreakpointsTableModel...
(1) I've submitted issue #61542. (2) I've modified the BreakpointsTableModel to handle setValueAt() asynchronously. It will prevent from deadlocks and improve UI responsiveness: /cvs/debuggercore/src/org/netbeans/modules/debugger/ui/models/BreakpointsTableModel.java,v <-- BreakpointsTableModel.java new revision: 1.5; previous revision: 1.4 /cvs/debuggercore/src/org/netbeans/modules/debugger/ui/models/BreakpointsTreeModel.java,v <-- BreakpointsTreeModel.java new revision: 1.6; previous revision: 1.5
Okay, verifying on behalf of Jarda.