Eclipse RCP中IEventBroker重复触发handleEvent及处理异常问题排查

Alright, let's tackle this duplicate event trigger issue you're seeing with Eclipse RCP's IEventBroker. I've run into similar quirks when working with RCP event handling, so here's what's likely going on and how to fix it:

First, Diagnose the Root Cause #

The fact that the same Event instance (same hashcode, topic, and data) is being processed multiple times usually points to duplicate event subscriptions in your Receiver view. Here's why that happens:

• If your Receiver view is created/destroyed multiple times (e.g., closing and reopening the view, or having multiple instances of the view), and you don't properly unsubscribe from the event broker when the view disposes, old subscriptions will linger. Each active subscription will trigger handleEvent for the same event.
• Less commonly, you might be accidentally adding the subscription multiple times in createPartControl (e.g., inside a loop or a method that runs repeatedly).

Solutions to Control handleEvent Call Count #

1. Ensure Proper Subscription & Unsubscription #

The most critical fix is to register your event subscription exactly once per view instance, and dispose of it when the view is destroyed. Here's how to adjust your Receiver code:

import org.eclipse.ui.part.ViewPart;
import org.eclipse.e4.core.services.events.IEventBroker;
import org.eclipse.e4.core.di.dispose.IDisposable;

public class ReceiverView extends ViewPart {
    private IDisposable eventSubscription;

    @Override
    public void createPartControl(Composite parent) {
        // Your existing view initialization code...

        // Register the event subscription ONCE
        IEventBroker eventBroker = PlatformUI.getWorkbench().getService(IEventBroker.class);
        eventSubscription = eventBroker.subscribe(MyEventConstants.TOPIC_OBJECT_CHANGED, this);
    }

    @Override
    public void dispose() {
        // Unsubscribe when the view is disposed to clean up old subscriptions
        if (eventSubscription != null && !eventSubscription.isDisposed()) {
            eventSubscription.dispose();
        }
        super.dispose();
    }

    // Your existing handleEvent method here...
}

2. Add a Deduplication Check in handleEvent #

As a safety net, you can add a simple check to skip processing the same Event instance multiple times. This is useful if you can't track down all duplicate subscription sources:

private Object lastProcessedEvent;

@Override
public void handleEvent(Event event) {
    // Skip duplicate processing of the same event instance
    if (event == lastProcessedEvent) {
        return;
    }
    lastProcessedEvent = event;

    // Your existing event handling logic...
    Object data = event.getProperty(Event.EVENT_DATA);
    switch (event.getTopic()) {
        case MyEventConstants.TOPIC_OBJECT_CHANGED:
            try {
                if (data instanceof ArrayList) {
                    List<MyObject> matches = null;
                    try {
                        matches = (List<MyObject>) data;
                    } catch (ClassCastException e) {
                        // Add logging here to debug casting issues
                        e.printStackTrace();
                    }

                    // Guard against null matches to avoid unexpected failures
                    if (matches != null) {
                        Subthing sub = buildSubthing(matches);
                        // Ensure UI updates run on the UI thread
                        Display.getDefault().asyncExec(() -> {
                            getContentViewer().getContents().setAll(Collections.singletonList(sub));
                        });
                    }
                }
            } break;
    }
}

3. Fix Potential Issues in buildSubthing #

You mentioned buildSubthing becomes unresponsive for some data. Even if the data structure is the same, here's what to check:

• UI Thread Blocking: If buildSubthing performs heavy processing, it will block the UI thread causing unresponsiveness. Move the work to a background job, then update the UI on the UI thread:

  if (matches != null) {
      Job buildJob = new Job("Building Subthing") {
          @Override
          protected IStatus run(IProgressMonitor monitor) {
              Subthing sub = buildSubthing(matches);
              // Update UI on the correct thread
              Display.getDefault().asyncExec(() -> {
                  getContentViewer().getContents().setAll(Collections.singletonList(sub));
              });
              return Status.OK_STATUS;
          }
      };
      buildJob.schedule();
  }
  

• Null or Invalid Data: Even if the structure looks the same, check for null elements in matches or unexpected values that might cause buildSubthing to hang. Add logging inside buildSubthing to track its execution flow.

4. Verify Triggerer's Event Sending Logic #

Double-check that your Triggerer isn't sending the event multiple times accidentally:

• Ensure the SelectionListener is added to the button only once (e.g., in createPartControl, not in a method that runs on view activation).
• Check if matches is being populated correctly without duplicates that might trigger unintended sends.

内容的提问来源于stack exchange，提问作者s.d