Bugzilla – Full Text Bug Listing
| Summary: | Acquire a lock could notify others | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Stephane fournier <stephane.fournier> | ||||||||||
| Component: | cdo.core | Assignee: | Eike Stepper <stepper> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Eike Stepper <stepper> | ||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | jpsilvagallino, smcduff, stepper | ||||||||||
| Version: | 4.2 | Keywords: | helpwanted | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Stephane fournier
I think the best places to start investigation are these: - org.eclipse.emf.cdo.server.internal.net4j.protocol.LockObjectsIndication - org.eclipse.emf.cdo.server.internal.net4j.protocol.UnlockObjectsIndication They both use org.eclipse.emf.cdo.internal.server.LockManager . Examples for async notifications are here: - org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitNotificationRequest - org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificationIndication In the end this feature should be configurable (on/off) on the client side per session or per view. Please let me know if you need more info ;-) I think we see more and more people requesting a communication layer between objects. Could we add something more generic to be able to notify others with a generic notifications define by the user ? The user would be able to define its own type of notification and it will be transfered to others. (Not implementation.. something like objectLocks.cdoFireEvent(new CDONotification(STEPHANE.LOCKOBJECT)); At this point it would be up to the client to decide when a notification should be sent. The disadvantages is to have it done manually. I`m not against this feature.... only I don`t know yet if I like it or not ? :-) I would prefer this approach since it will allows more people to decide whenever they want to notify others. If a notification is used by many people.. maybe we could add it in the framework. Stéphane would you be happy with this situation ? Simon (In reply to comment #2) > I think we see more and more people requesting a communication layer between > objects. > Could we add something more generic to be able to notify others with a generic > notifications define by the user ? > The user would be able to define its own type of notification and it will be > transfered to others. (Not implementation.. something like > objectLocks.cdoFireEvent(new CDONotification(STEPHANE.LOCKOBJECT)); > > At this point it would be up to the client to decide when a notification should That fits my needs. Nevertheless, how to receive the notification ? Who owns the listener ? The session ? The view ? On user B, if the object is not already loaded, what happens ? > be sent. The disadvantages is to have it done manually. > > I`m not against this feature.... only I don`t know yet if I like it or not ? > :-) > > I would prefer this approach since it will allows more people to decide > whenever they want to notify others. > If a notification is used by many people.. maybe we could add it in the > framework. > > Stéphane would you be happy with this situation ? > > Simon > Some time ago I started with a RemoteSessionManager but I think "CollaborationManager" might be a better name. The idea is that a local session knows about all remote sessions and can communicate with them (sending text messages, etc). This "visibility" is designed to be optional, i.e. only if a local session "subscribes" itself it becomes visible for other emote sessions. This mechanism is not completely implemented yet although the bulk of the client side API is already available. Are you interested in helping us to complete this functionality? --- That said, I also like the idea of having lock/unlock notification with proper API in the core. I leave it to you what you would like to start with ;-) (In reply to comment #4) > Some time ago I started with a RemoteSessionManager Update: This collaboration facility is fully spec'ed, implemented and is even supported by the generic UI. See bug 260908 Some hints and start points: 1) At the server side locking is managed by org.eclipse.emf.cdo.internal.server.LockManager and org.eclipse.net4j.util.concurrent.RWLockManager. They lock CDOIDs in IViews (the server side equivalents to a client side CDOViews). 2) Lock notifications should be limited to those clients that are really interested in them. Applications should register a dedicated listener with their local view and the existence of at least one such listener should be known to the server. This requires an active and synchronous registration/deregistration protocol. The "hasListenerRegistered" information must be stored and made available via IView. The LockManager should maintain a collection of ISessions that have IViews with hasListenerRegistered==true. 3) Whenever the locking state of an object (represented of a CDOID) changes in the context of a view the LockManager must send asynchronous notifications to the sessions in the collection. The receiving CDOSessions will trigger their interested CDOViews to fire respective events to their listeners. 4) For either side of the protocol to receive new signals a subclass of Indication (async) or IndicationWithResponse (sync) has to be created and instantiated appropriately in the createSignalReactor() method of the protocol. See org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerProtocol and org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol. Note that we decoupled CDO from Net4j. As a consequence protocol changes are first to be made in CDOSessionProtocol! Created attachment 151848 [details]
Modified CDO and NET4J plugins only. Part 1/2
Hi Eike.
Disregard the client part of this code, just focus on the server part.
I added the following code to the indicating menthod of org.eclipse.emf.cdo.server.internal.net4j.protocol.LockObjectsIndication:
for (InternalSession session : getRepository().getSessionManager().getSessions())
{
if (session.hasListeners())
{
session.getProtocol().sendRemoteLockNotification(view, ids, lockType);
}
}
and the method sendRemoteLockNotification in CDOServerProtocol. I also declared a new CDOProtocolConstants.SIGNAL_REMOTE_LOCK = 35.
It is currently resulting in a NPE. The packageRegistry and uri obtained from the BufferInputStream are null.
The stack trace of the resulting exception is attached below.
Regards,
JP
[ERROR] NullPointerException
java.lang.NullPointerException
at org.eclipse.emf.common.util.URI.createURIWithCache(URI.java:669)
at org.eclipse.emf.common.util.URI.createURI(URI.java:541)
at org.eclipse.emf.cdo.common.model.EMFUtil.createEcoreResource(EMFUtil.java:269)
at org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:248)
at org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:393)
at org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:282)
at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:88)
at org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.readCDOPackageUnits(CDODataInputImpl.java:103)
at org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificationIndication.indicating(CommitNotificationIndication.java:56)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndication.indicating(CDOClientIndication.java:54)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indication.java:55)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
at org.eclipse.net4j.signal.Indication.execute(Indication.java:49)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Created attachment 151850 [details]
Modified CDO and NET4J plugins only. Part 2/2
Hi Juan Pedro, The patches yuo attached are no patches. They are incredibly large. Did you copy a complete workspace instead of creating a patch of only the changes? To be able to review your code I need a single patch that is created against the workspace root (unified format). Please let me know if you need more infos on how to create such a patch. From the stacktrace I can see that the client assumes an incoming CommitNotificationIndication. That's why I suspected you messed up the signals IDs. Hi Eike.
Sorry about that, yes, I attached the modified plugins as a whole.
I'll upload a patch next time.
I found the cause of the wrong signal you where pointing out, so I'll keep going forward before uploading a new version.
Regards,
JP
(In reply to comment #9)
> Hi Juan Pedro,
>
> The patches yuo attached are no patches. They are incredibly large. Did you
> copy a complete workspace instead of creating a patch of only the changes? To
> be able to review your code I need a single patch that is created against the
> workspace root (unified format). Please let me know if you need more infos on
> how to create such a patch.
Created attachment 152326 [details]
Notification patch. Working.
Hi Eike.
I'm uploading a working patch. Sorry for the delay, I got caught by other activities.
In the patch you will find an implementation of the registration of listeners and the notification of remote locks acquired and released. I'm sure you can come up with a better/more elegant implementation; I'm posting this so you can point out improvements you would like to see in it.
The UI part is not implemented yet, and currently there is a hard-coded registration of listeners by the editor, and received events print a comment on the err console as a means of notification. Test cases are also not available at this time. I included the view registration mechanism as requested, but I'm currently not using it.
There are still some things that remain to be defined, the most remarkable of which is the contents of the CDODataInput to be send with the notifications. I payed little attention to it.
I hope you fin this useful. I could provide some sort of description of the notification process if you consider it necessary.
Regards,
Juan Pedro
Created attachment 153394 [details]
Improved version. Working
A new implementation.
-Application (i.e., CDOEditor) register listeners in views.
-Views register themselves in sessions as interested in remote locks.
-Sessions, in turn, ask CDOClientProtocol to signal (un)register to the repository lockManager when appropriate. (one signal defined to register, another to unregister).
-RWLockManager keeps tracks of registered sessions, and signals remotelockchangednotifications at new (un)locks. (one new signal)
-RemoteLockChangedIndication reacts to the signal, notifying only those views with hasRegisteredListeners = true;
-CDOViewImpl fires appropriate events to registered listeners.
I hope you like it.
Regards,
Juan Pedro
Rebasing all outstanding enhancements requests to version 4.0 Moving all open enhancement requests to 4.1 Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. Dup of bug 353691. *** This bug has been marked as a duplicate of bug 353691 *** Closing |