I now removed our custom code - I don't think it has something to
do with this issue.
current state:
on every client connect one ore more (depending on the number of
published services) "ID targetContainerID" Objects are added to a
List in the Map localRegistryUnregistrationTargets in the
RegistrySharedObject on the Server Side.
the call stack is:
Daemon Thread
[org.eclipse.ecf.remoteservice.IRemoteServiceContainerAdapter:run]
(Suspended (breakpoint at line 1633 in RegistrySharedObject))
owns: RemoteServiceRegistryImpl (id=252)
RegistrySharedObject.addTargetForUnregister(RemoteServiceRegistrationImpl,
ID) line: 1633
RegistrySharedObject.sendAddRegistrations(ID, Integer,
RemoteServiceRegistrationImpl[]) line: 1253
RegistrySharedObject.sendRegistryUpdate(ID, Integer) line:
775
RegistrySharedObject.handleRegistryUpdateRequest(ID, Integer)
line: 1128
GeneratedMethodAccessor35.invoke(Object, Object[]) line: not
available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line:
43
Method.invoke(Object, Object...) line: 498
SharedObjectMsg.doInvoke(Object) line: 323
SharedObjectMsg.invoke(Object) line: 290
RegistrySharedObject.handleSharedObjectMsg(SharedObjectMsg)
line: 1843
RegistrySharedObject(BaseSharedObject).handleSharedObjectMsg(ID,
SharedObjectMsg) line: 467
RegistrySharedObject(BaseSharedObject).handleSharedObjectMsgEvent(ISharedObjectMessageEvent)
line: 457
SharedObjectMsgEventProcessor.processSharedObjectMsgEvent(ISharedObjectMessageEvent)
line: 41
SharedObjectMsgEventProcessor.processEvent(Event) line: 36
RegistrySharedObject(BaseSharedObject).fireEventProcessors(Event)
line: 192
RegistrySharedObject(BaseSharedObject).handleEvent(Event)
line: 126
SOWrapper.svc(Event) line: 182
SOWrapper$2.run() line: 138
Thread.run() line: 745
I don't see any code that removed entries from the List in Map
when the Client disconnects. So the List (and with it the Map
localRegistryUnregistrationTargets) grows until there is no memory
left.
Any help on this topic would greatly be appreciated.
thx Peter
Am 15.03.2017 um 15:52 schrieb Peter
Hermsdorf:
Hi all,
sorry for double posting - hotkeys are evil sometimes...
for custom error handling on server side (please see previous
discussion on this list as of 27.06.2014 with the subject
"Exception Handling of Remote Calls") we use a derived
HostContainerSelector and a derived RegistrySharedObject. See code
below.
The problem seems to be that we create a instance of
RegistrySharedObject (P4RegistrySharedObject()) wich gets added to
org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.localRegistryUnregistrationTargets
but "no one" calls
org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.sendUnregister(RemoteServiceRegistrationImpl)
when the remote client disconnects.
So the Map grows over time and finally the server run's into an
OutOfMemory Exception after some time.
Any suggestions where the Problem is or what is missing from the
implementation?
thanks in advance!
Best Regards, Peter
BTW: we are running ECF 3.13.1.v20160405-1820
extended HostContainerSelector:
@Override
protected IRemoteServiceContainer createRSContainer(
@SuppressWarnings("rawtypes") final ServiceReference
serviceReference, final Map<String, Object> properties,
final ContainerTypeDescription
containerTypeDescription) throws SelectContainerException {
final ISharedObjectContainer container =
(ISharedObjectContainer) createContainer(serviceReference,
properties,
containerTypeDescription);
final ID adapterID =
IDFactory.getDefault().createStringID(IRemoteServiceContainerAdapter.class.getName());
final ISharedObjectManager manager =
container.getSharedObjectManager();
ISharedObject so = manager.getSharedObject(adapterID);
if (so == null) {
so = new P4RegistrySharedObject();
try {
manager.addSharedObject(adapterID, so, null);
} catch (final SharedObjectAddException e) {
throw new P4ServerException(e);
}
}
return new RemoteServiceContainer(container,
(IRemoteServiceContainerAdapter) so);
}
P4RegistrySharedObject extends RegistrySharedObject and just
implements a custom getSerializableException method - since the
original one is private, it's a copy of the executeRequest
method.
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
Mit
freundlichen Grüßen
Peter Hermsdorf
|
GODYO
Business Solutions AG
Prüssingstraße
35
07745 Jena
|
Peter
Hermsdorf
Senior
Software Developer
Teamleiter Softwareentwicklung
|
E-Mail:
peter.hermsdorf@xxxxxxxxx
Telefon: +49 3641 287-0
Telefax: +49 3641 287-287
Mobil: +49 151 287111
Internet: www.godyo.com
|

GODYO Business
Solutions AG,
Prüssingstraße 35, 07745 Jena,
Ein Unternehmen der ACP Gruppe
Vorstand:
Hans-Uwe Schramm,
Aufsichtsratsvorsitzender: Günther Schiller,
Amtsgericht Jena HRB 502 129
Diese E-Mail
ist vertraulich.
Wenn Sie nicht der vorgesehene Empfänger sind, verwenden Sie
bitte keine
Inhalte dieser E-Mail und leiten sie diese auch nicht
weiter. Wenn Sie
fälschlicherweise diese E-Mail bekommen haben, informieren
Sie uns bitte
umgehend und löschen dieses Dokument. This
e-mail is confidential. If you are not the intended
recipient, please do not
disclose or use the contents of the e-mail. If you have
erroneously received
this e-mail, please inform us immediately by return e-mail
and delete the
document.
|