{"action":"opened","issue":{"url":"https://api.github.com/repos/wongatech/SLAMonitor/issues/7","labels_url":"https://api.github.com/repos/wongatech/SLAMonitor/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/wongatech/SLAMonitor/issues/7/comments","events_url":"https://api.github.com/repos/wongatech/SLAMonitor/issues/7/events","html_url":"https://github.com/wongatech/SLAMonitor/issues/7","id":101391481,"number":7,"title":"Asynchronous SLAMonitor keeps trace data in memory that may leak if response never arrive","user":{"login":"Suremaker","id":1894621,"avatar_url":"https://avatars.githubusercontent.com/u/1894621?v=3","gravatar_id":"","url":"https://api.github.com/users/Suremaker","html_url":"https://github.com/Suremaker","followers_url":"https://api.github.com/users/Suremaker/followers","following_url":"https://api.github.com/users/Suremaker/following{/other_user}","gists_url":"https://api.github.com/users/Suremaker/gists{/gist_id}","starred_url":"https://api.github.com/users/Suremaker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Suremaker/subscriptions","organizations_url":"https://api.github.com/users/Suremaker/orgs","repos_url":"https://api.github.com/users/Suremaker/repos","events_url":"https://api.github.com/users/Suremaker/events{/privacy}","received_events_url":"https://api.github.com/users/Suremaker/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-08-17T10:34:25Z","updated_at":"2015-08-17T10:34:25Z","closed_at":null,"body":"Currently SLAMonitor keeps all trace data in memory.\r\n\r\nWhen request is being made, it records the request, correlation id and time in memory.\r\nOn response arrival, the trace data is analysed and memory is freed.\r\n\r\nNow it may happen that the response would never come back (target service is down), causing memory leak in SLAMonitor. It is also possible to SLAMonitor would use too much memory if target service is less efficient and many requests are being sent.\r\n\r\n**Proposed solutions**\r\n\r\n1. SLAMonitor should use temporary persistence for it's data\r\nIn this scenario, the data would be kept on local drive (service local data) and it would be erased on service restart, as in most cases, the SLA would be violated if service was down\r\n\r\n2. SLAMonitor should allow to timeout the request\r\nIn this scenario, while data would be still kept in memory, it would be automatically discarded (with some error message) if SLA is heavily violated (2x time maybe?)"}}