Hi Minxuan, I followed the steps you suggested. Once I stop BasicConsumer I actually receive a notification about it but in the 'Applications' page I still see both 'demo-consumer' and 'demo-provider'. The only difference I noticed is that 'demo-consumer' has both 'Providers' and 'Consumers' columns to 0, while 'Consumers' was 1 before I stop it. This make perfectly sense, but I would expect that once you have no more running instances of a given application, this one would be removed from 'Applications' page list. I also had a look at the code of class RegistryContainer from project 'incubator-dubbo-ops/dubbo-monitor-simple/' which is the class that receives notifications from registry. I noticed that applications are stored in a Set variabile where 'remove' method is never called (here is the variable 'https://github.com/apache/incubator-dubbo-ops/blob/ master/dubbo-monitor-simple/src/main/java/com/alibaba/dubbo/monitor/simple/ container/RegistryContainer.java#L46') so I guess it was meant to work like this (i.e. applications are never removed), right?
<https://github.com/apache/incubator-dubbo-ops> On Thu, Jul 12, 2018 at 10:57 PM, Andrea Del Bene <[email protected]> wrote: > Hi, > > thank you for your reply. So far I used a stand-alone broadcast registry. > I will try to follow the steps you suggested me. > > > > On 12/07/2018 16:46, Minxuan Zhuang wrote: > >> Hi >> Thank you for being interested in Dubbo monitor, If you unregister a >> a >> consumer, the monitor will get the information Immediately, >> you can try this by the steps below: >> 1. start a zookeeper >> 2 start Dubbo monitor by running MonitorStarter.java >> 3. download dubbo samples here <https://github.com/dubbo/dubbo-samples> >> and >> run dubbo-samples-monitor module >> If you start both BasicProvider and BasicConsumer, you can see provider >> and >> consumer info on dubbo monitor, once you stop BasicConsumer, this consumer >> info will disappear. the monitor can detect the change by NotifyListener >> and this mechanism is very efficient for me, do you have any >> suggestion for implementing >> this? >> >> On Wed, Jul 11, 2018 at 5:29 PM Andrea Del Bene <[email protected]> >> wrote: >> >> Hi, >>> >>> I'm very new to Dubbo but I'd like to share some ideas. I am playing >>> around >>> trying to implement a simple monitor for Dubbo (this one >>> https://github.com/bitstorm/wicket-coreui). To start grasping what I >>> have >>> to do I've looked at what dubbo-monitor-simple ( >>> https://github.com/apache/incubator-dubbo-ops) already does. While the >>> overall mechanism is quite clear I find difficult working with the >>> current >>> URL-based notification mechanism (I'm referring to interface >>> NotifyListener). Extracting informations from url is not trivial and I >>> think we might use a more complex and clear object for this task. In >>> particular is difficult to be notified if a consumer application has been >>> unregistered. >>> >>> Hope this could be helpful for future improvements. >>> >>> Thank you. >>> >>> On Mon, Jul 9, 2018 at 9:32 AM, Liujie Qin <[email protected]> wrote: >>> >>> Hi All, Dubbo has become a excellent RPC framework with the efforts of >>>> various partners in the community. However, in the process of >>>> >>> development, >>> >>>> we found some shortcomings of Dubbo 2.x, which is listed as follows: >>>> >>>> - The maintainability is relatively poor. The code uses a lot of >>>> dynamically generated classes. It is difficult to understand and >>>> difficult >>>> to debug. The code hierarchy is not clear enough, and the calling >>>> >>> logic >>> >>>> is >>>> confusing. As an experienced Dubbo developer, sometimes it is >>>> >>> difficult >>> >>>> for >>>> me to sort out the calling process of Dubbo 2.x; the more developed, >>>> >>> the >>> >>>> more difficult it is to maintain, so it needs to be refactored in >>>> >>> order >>> >>>> to >>>> develop better. >>>> - Some extensions cannot meet current needs, such as service >>>> addresses >>>> push monitoring, performing Filter early interception requests >>>> before >>>> service addresses selection, printing the process of route >>>> selection, >>>> etc. >>>> - The underlying Dubbo 2.X is based on synchronous calls. The >>>> asynchronous call is wrapped synchronously. This introduces >>>> >>> inaccuracies >>> >>>> such as RT during asynchronous calls. >>>> - At present, the service metadata information and the address of >>>> the >>>> Dubbo service are coupled together. Most of the metadata is the >>>> same, >>>> and >>>> the metadata is redundant. At the same time, as the size of the >>>> >>> machine >>> >>>> increases, the Registry is under great pressure, especially when >>>> >>> machine >>> >>>> restart. >>>> - The service registry and the configuration center are coupled >>>> together, and after splitting, the management and storage of service >>>> governance rule data such as routing rules can be better handled. >>>> - The core is written based on JDK 1.6 and cannot use the newer JDK >>>> features. It is recommended to upgrade JDK to 1.8 and above. >>>> >>>> For the above reasons, in order to better develop Dubbo and attract more >>>> people to participate in the development of the Dubbo community, I >>>> >>> propose >>> >>>> to refactor the Dubbo 2.x code. The newly developed version number is >>>> >>> Dubbo >>> >>>> 3.x. Refactoring Dubbo 3.x will have the following advantages: >>>> >>>> - Refactoring core modules to make the code more concise and >>>> understandable >>>> - Refactoring the routing process, Making the route process to >>>> >>> Pipeline >>> >>>> style,Making the route process can be observed >>>> - Add new extension points to make it easier for developers to >>>> extend >>>> the framework >>>> - Add the Service Domain Model to enable developers to handle its >>>> lifecycle >>>> - Supports asynchronous interface, unified call process returns >>>> CompleteFuture, synchronous call process uses CompleteFuture >>>> wrapper; >>>> Solve >>>> the problem of inaccurate statistics such as RT during asynchronous >>>> >>> call >>> >>>> - Splitting out the Configuration Center and Registry for better >>>> >>> control >>> >>>> and support for larger clusters >>>> - Prepare for new features such as Http2 stream、Reactive stream >>>> - Performance improvement >>>> - And so on >>>> >>>> Of course, refactoring Dubbo 3.x also faces the following challenges: >>>> >>>> - A wide range of refactorings that can cause extension points to be >>>> incompatible >>>> - The Dubbo team may need to maintain two branches at the same time >>>> >>> for >>> >>>> a longer period of time >>>> >>>> For the following challenges, we can do this: >>>> >>>> - >>>> >>>> For major extension points, such as Fitler, etc., be sure to ensure >>>> compatibility and enable developers to smoothly upgrade >>>> - >>>> >>>> For some extension points, the Dubbo team will listen to the >>>> community >>>> and selectively fix compatibility issues with some extension points. >>>> >>>> Comments welcome! >>>> >>>> thank you ~ >>>> >>>> >>> >>> -- >>> Andrea Del Bene. >>> Apache Wicket committer. >>> >>> > -- Andrea Del Bene. Apache Wicket committer.
