[MNEMONIC-588] Re-design the memory service selection mechanism

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.14.0
• Fix Version/s: 0.14.0
• Component/s: Memory-Service
• Assignee: Xiaojin Jiao
• Reporter: Gordon King
• Due: 02/Feb/21
• Created: 10/Jan/21 01:02
• Updated: 01/Mar/21 18:02
• Resolved: 01/Mar/21 18:02

Description

The memory service loading relies on the old JDK extension mechanism that has got removed in JDK10 and later, please refer to the following linked page.

https://docs.oracle.com/javase/10/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B

 

Sub-Tasks

• Replace the Utils.getVolatileMemoryAllocatorService call from Example: Closed
• Replace the Utils.getNonVolatileMemoryAllocatorService call from Collections: Closed
• Replace the Utils.get*MemoryAllocatorService call from Core: Closed
• Replace the Utils.getVolatileMemoryAllocatorService from Benches: Closed
• Replace the Utils.getNonVolatileMemoryAllocatorService call from Computing Service: Closed
• Replace the Utils.getNonVolatileMemoryAllocatorService call from Spark and Hadoop: Closed
• Extract query and memory interface from mnemonic-core to mnemonic-common: Closed
• Extract service-memory interface from mnemonic-core to mnemonic-common: Closed
• Cleanup query, service-memory, service-computing interface from mnemonic-core: Closed
• Replace mnemonic-core dependency with mnemonic-common in mnemonic-memory-service: Closed
• Add relevant memory service dependency for mnemonic-hadoop: Closed
• Add relevant memory service dependency for mnemonic-core: Resolved
• Add Utils.getVolatileMemoryAllocatorService call back to Example: Closed
• Add Utils.getNonVolatileMemoryAllocatorService call back to Collections: Closed
• Add Utils.getVolatileMemoryAllocatorService call back to Benches: Closed
• Add Utils.getNonVolatileMemoryAllocatorService call back to Computing Service: Closed