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.

Bug 37505 - Support different request / response architectures of different SPI implementations.
Summary: Support different request / response architectures of different SPI implement...
Status: VERIFIED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC Linux
: P1 blocker (vote)
Assignee: issues@debugger
URL:
Keywords: API, PERFORMANCE
: 34335 (view as bug list)
Depends on:
Blocks: 27194
  Show dependency tree
 
Reported: 2003-11-26 11:01 UTC by Jaroslav Tulach
Modified: 2006-07-28 15:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2003-11-26 11:01:02 UTC
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.
Comment 1 Jaroslav Tulach 2003-11-26 11:19:58 UTC
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.
Comment 2 Jan Jancura 2003-11-26 14:53:42 UTC
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.

Comment 3 Jan Jancura 2003-11-26 14:55:44 UTC
BTW: There is similair issue on debugger API for a long time:
http://www.netbeans.org/issues/show_bug.cgi?id=34335
Comment 4 ivan 2003-11-26 23:14:46 UTC
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.
Comment 5 Jan Jancura 2003-11-27 09:11:30 UTC
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?
Comment 6 Jaroslav Tulach 2003-12-03 13:54:50 UTC
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.
Comment 7 Jan Jancura 2003-12-15 09:32:43 UTC
Planned for Promo D
Comment 8 Jan Jancura 2003-12-15 10:38:56 UTC
*** Issue 34335 has been marked as a duplicate of this issue. ***
Comment 9 Jaroslav Tulach 2004-03-25 07:52:23 UTC
Turning into real TCR, waiting for debugger team to evaluate.
Comment 10 Jan Jancura 2004-03-26 15:11:53 UTC
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.
Comment 11 Max Sauer 2005-07-11 16:14:16 UTC
Jardo, could You please verify this issue?
Comment 12 ivan 2005-07-11 19:48:18 UTC
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.
Comment 13 Jaroslav Tulach 2005-07-12 10:23:02 UTC
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. 
Comment 14 ivan 2005-07-12 19:17:25 UTC
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.
Comment 16 Martin Entlicher 2005-07-21 10:59:20 UTC
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.
Comment 17 ivan 2005-07-21 20:42:08 UTC
(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.



Comment 18 Martin Entlicher 2005-07-25 14:06:26 UTC
(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.
Comment 19 ivan 2005-07-25 22:53:02 UTC
(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.

    
    
    
Comment 20 Martin Entlicher 2005-07-28 15:36:10 UTC
(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...
Comment 21 Martin Entlicher 2005-07-29 12:44:04 UTC
(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
Comment 22 Jiri Kovalsky 2006-07-28 15:29:40 UTC
Okay, verifying on behalf of Jarda.