Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have tested the MantaRay's performance weeks before, the figures presents that the bottleneck is disk and network I/O for MantaRay; so that if the producer's speed is more fast than receiver(or the network is interrupted), then you will get Out of Memory error soon, and this error may occur again when recover the messages from disk, those because MantaRay is a pure memory based article, it pre-load all the message into memory from disk through PersistentMap, and memory inside sorting to keep the FIFO(PostOfficeBox, QueueService); I cannot stick it out for the OOM error, and try to load the message from disk just in time. there is a path for who will reduce the memroy expense:
1. modify the PersistentMap prevent load the messages into memory from disk in recover function.
2. directly load the message from disk for every access, you can transform the message ID to file name by entryToMap(a hashmap maintained in persistent map).
3. you'd create a digestor for hold the necessary information of JMS for sorting and other manipulations, I think hold MantaBusMessage's properties and JMS timestamp except payLoad is enough.
4. modify the JMS associates code in PostOfficeBox and QueueService to replace the MantaBusMessage with its digestor.
5. anything else? I am trying, maybe a summary later.
It's running now.
Hi can you post your fixes for this situation? We are seeing similar issues.