[jbosstools-issues] [JBoss JIRA] (JBIDE-26697) Possible memory leak during Loading projects job when using CRC

[ https://issues.jboss.org/browse/JBIDE-26697?page=com.atlassian.jira.plugi... ] André Dietisheim edited comment on JBIDE-26697 at 10/21/19 10:22 AM: --------------------------------------------------------------------- I see 3 possible approaches to fix this situation: * Watch events only: Possible but there are 2 problems: ** We need the resource instance that's affected. In an event we only have the affected object which provides name, namespace, timestamp etc. and lacks the resource instance. We thus have to introduce an additional call to the backend to retrieve this resource. ** the change type that we provide when informing of changes: events are always "ADD". We'd thus have to guess "DELETE" and "MODIFY" change types via the event message. Usually pods that are killed are notified with a "Killing" message, new pods via "Created". Every other event then would be a "MODIFIED". This solution seems possible but unreliable. The code for this could look like the following: {code} IEvent event = (IEvent) resource; IObjectReference reference = event.getInvolvedObject(); String name = reference.getName(); String namespace = reference.getNamespace(); String kind = reference.getKind(); IResource res = conn.getResource(kind, namespace, name); String message = event.getMessage(); ChangeType guessedChange = null; if (message.contains("Killing")) { guessedChange = ChangeType.DELETED; } else if (message.contains("Created")) { guessedChange = ChangeType.ADDED; } else { guessedChange = ChangeType.MODIFIED; } {code} * hack the okHttp Dispatcher so that we're reusing the same thread of watcher requests: Dispatcher#exeuted(Call) calls the dispatcher for a call. The dispatcher creates a thread for the call. Call#request() returns the request where via Request#url we could verify if we're dispatching for a watcher. The con for this is that we're actually contradicting the okHttp design principles * use a 2nd client for the watcher part: use AsyncHttpClient which does not force a 1/1 model for requests/threads: https://github.com/AsyncHttpClient/async-http-client/ was (Author: adietish): I see 3 possible approaches to fix this situation: * Watch events only: Possible but there are 2 problems: ** We need the resource instance that's affected. In an event we only have the affected object which provides name, namespace, timestamp etc. and lacks the resource instance. We thus have to introduce an additional call to the backend to retrieve this resource. The code for this could look like the following: {code} IEvent event = (IEvent) resource; IObjectReference reference = event.getInvolvedObject(); String name = reference.getName(); String namespace = reference.getNamespace(); String kind = reference.getKind(); IResource res = conn.getResource(kind, namespace, name); String message = event.getMessage(); ChangeType guessedChange = null; if (message.contains("Killing")) { guessedChange = ChangeType.DELETED; } else if (message.contains("Created")) { guessedChange = ChangeType.ADDED; } else { guessedChange = ChangeType.MODIFIED; } {code} ** the change type that we provide when informing of changes: events are always "ADD". We'd thus have to guess "DELETE" and "MODIFY" change types via the event message. Usually pods that are killed are notified with a "Killing" message, new pods via "Created". Every other event then would be a "MODIFIED". This solution seems possible but unreliable. * hack the okHttp Dispatcher so that we're reusing the same thread of watcher requests: Dispatcher#exeuted(Call) calls the dispatcher for a call. The dispatcher creates a thread for the call. Call#request() returns the request where via Request#url we could verify if we're dispatching for a watcher. The con for this is that we're actually contradicting the okHttp design principles * use a 2nd client for the watcher part: use AsyncHttpClient which does not force a 1/1 model for requests/threads: https://github.com/AsyncHttpClient/async-http-client/ -- This message was sent by Atlassian Jira (v7.13.8#713008)