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 <an.delb...@gmail.com>
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 <liujie...@apache.org> 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.
>
