[MGNLUI-3775] Design a dedicated component to handle temporary files lifecycle Created: 16/Feb/16  Updated: 10/Mar/17  Resolved: 10/Mar/17

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.4.4
Fix Version/s: None

Type: New Feature Priority: Neutral
Reporter: Ilgun Ilgun Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLDAM-636 The Upload & Edit action does not wor... Closed
is related to MGNLUI-3776 Remove AppLifecycleEvent handler from... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:
Story Points: 13

 Description   

Attempts to solve issues related to clean-up of temporary files produced by form fields (MGNLDAM-636 and MGNLUI-3776) via a direct subscription to app/sub-app lifecycle events turned out to be rigid and error-prone: the same field type might be used in the scope of both sub-app and app (or even outside of both of them - e.g. in Pulse which exists in AdminCentral scope) => all those cases would have to be handled separately.

One possible solution to this problem is to abstract from the actual specific type of the UIContext:

  • design a map-like temporary file storage
  • create temporary files through such storage (i.e. create a mere tmp file, but map it internally to the current UiContext)
  • provide capabilities to clean-up the storage per UiContext, so that all the apps/sub-apps could do remove tmp files related to them in an automatic way (in their #close() method or something).
  • I would maybe use the WeakHashMap internally for such a component, so that the storage wouldn't prevent "dead" UiContext instances from being GC'ed in case clean-up didn't happen (e.g. that specific UiContext just doesn't do that, failed to do that or whatnot and => it's the cron job's work in such case)


 Comments   
Comment by Mikaël Geljić [ 09/Mar/17 ]

Was for temp upload files, but seems no-one complains about whatever solution we have for it at the moment (be it scheduled or on subapp close).

That said, my gut feelings tell me the servlet container should take care of that, not us.
(Or maybe we don't close multi-part input streams properly).

Comment by Michael Mühlebach [ 10/Mar/17 ]

Well, knowing our code ... not closing things is our thing (Shutdown tomcat properly and look at the log file)

But if I understood you correctly we don't need it atm or maybe not even at all?

Comment by Mikaël Geljić [ 10/Mar/17 ]

Unless proven otherwise, correct.

Generated at Mon Feb 12 09:09:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.