Event queue cleanup, categorization & tests (JAMESII-423)

[JAMESII-148] Inconsistent event queue behavior if events can be equal without being identical Created: 31/May/12  Updated: 31/Jul/14

Status: Open
Project: James II
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public (Visible to EVERYONE.)

Type: Sub-task Priority: Major
Reporter: Arne Bittig Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: parameters
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Attachments: Zip Archive mylyn-context.zip    

 Description   

Some event queues use object identity, some use the .equals(...) method for comparing events, which is relevant when two equal but not identical events are enqueued. Toy example:

queue.enqueue(new Integer(1), 1.0);
queue.enqueue(1, 2.0);
queue.requeue(new Integer(1), 1.0);
queue.enqueue(2, 2.0);
System.out.println(queue.dequeueAll(2.0) + "/" + queue.dequeueAll());

As of this writing, it produces [1,2]/[1] for SimpleReBucketEQ, [2]/[1] for SimpleEQ and TLWBSTEQ and [1,2]/[1,1] for all others (or [2,1]/[1,1]). Changing the above line to "if (!this.event.equals(obj.getEvent()))" makes TreeMapEQ also produce [2]/[1], changing the HashMap in the SimpleEQ to an IdentityHashMap makes it join the [1,2]/[1,1] side.

Maybe the relevant factories should know which behavior their produced event queues exhibit, such that one can define filter criteria based on it?

Related:
Entry.compareTo contains {{if (this.event != obj.getEvent()) { result = 1; }}}, which seems to violate commutativity.



 Comments   
Comment by jh194 [ 31/May/12 ]

This is a known issue. Thanks for adding this to JIRA. So far it has not been resolved as there is no easy fix for all event queue implementations and as any non easy fix will harm the efficiency of the implementations. However, there are already ongoing discussions on how to resolve the problem in the future.

Comment by Arne Bittig [ 13/Nov/13 ]

unassigned, added hiwi label, changed description to reflect that this is a known issue

Generated at Fri Aug 14 07:07:13 CEST 2020 using JIRA 5.0.7#734-sha1:8ad78a62c71cf08b03545eb446cc3b9bb5ce37ad.