Community
Participate
Working Groups
Build: tptp.sdk-TPTP-4.3.0-200610060112 IBM JRE 5 SR 3 Steps to reproduce: 1) Import the CBE files attached into Eclipse all at once. 2) Open each of the logs in the log navigator. Actual Results: Some logs show the proper number records, while others state there are 0 of 0 records, and some that state there are 0 of 44 records, with no filter being applied. Expected Results: Logs records of all logs should be shown in log view Additional Information: Importing the logs one by one, or replacing logs that don't show records, shows the records properly.
Created attachment 51549 [details] Logs
Created attachment 51550 [details] Error
Alex is on vacation; you may want to redirect the bug
I cannot reproduce problem with the latest candidate build TPTP-4.3.0-200610090100. I unzipped the logs.zip into my local file system, and import the 10 cbe files into workbench. All 10 logs are imported fine with no error reports. Each of them contains 44 records.
works for me
I was able to reproduce the problem on my machine using the latest TPTP 4.2.1 driver, so the problem existed before Sheldon's refractoring. The problem is occuring only on multithreaded machines.
rasing to P1 major
Alex, please take a look.
Deferring this to 4.4 with approval from TPTP PG (given on 11/01/06). It cannot be contained in 4.3. Alex, please open a defect to add a readme item for it in 4.3.
Need investigation, provide rough estimate of 12h.
Targetting to iteration 3 and increasing priority to indicate it is planned for 4.4.
*** Bug 176618 has been marked as a duplicate of this bug. ***
Raising to critical as requested by a consuming product.
The problem was caused by colliding URIs when creating agents. The collision of URIs caused the loaders to write the data to the wrong agent. I introduced a static counter to reduce the chance of collision.
Created attachment 60870 [details] Patch Alex, Please check-in the patch. As discussed, you'll need to have the latest copy of org.eclipse.hyades.logging.adapter checked out if you would like to verify the patch.
Created this test case under org.eclipse.tptp.monitoring.tests\gui\Monitor.UI.ImportLog\Monitor.UI.ImportLog.Part1.ImportMultipleCBELogFiles
I have reviewed, tested and checked in the patch. Please mark the defect as being fixed. Thanks.
(In reply to comment #15) If you want to make it thread-safe you could create a syncronized method that will provide the unique ID(counter), you could place that method in a utility class where it would become reusable. Also instead of a counter you could use the System.currentTimeMillis() value and increment it only if it is <= last value of the ID (which is stored in a static field and updated on each call of getNextUniqueTimeID() method). Even when using this method if you want to make sure that the new resource doesn't collide with an existing one then you should check if such resource exist in the workspace already (althogh this case if very unlikely to happen when using the currentTimeMillis as the ID).
>(In reply to comment #18) The URI was already using a time stamp. The collisions were happenning because agents were being created in less than one millisecond apart.
Then fix the original timestamp instead of adding another element there, the file name is already too long.
(In reply to comment #20) As discussed (in person), I don't have access to the time stamp where I append the counter. Please feel free to assign it to yourself and increment the time stamp if you think that the fix is not sufficient.
(In reply to comment #21) I already explained my concerns with this approach so I'll let the component owner to decide if the fix is appropiate or not and if it covers all the scenarios.
I think for now the solution provided by Ali is sufficient. Perhaps a synchronized counter would have been a more safer solution indeed but this is working for now and solves the problem and giving the current time constraints that we have I think it's OK. If we encounter any problems in the future then we'll take it from there.
Just to be on the safe side I've added a synchronized block and a counter method.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
