Serialization exception within ProbeSpec Concurrent Blackboard
Description
When running the attached SpecJMS model with the included JMS middleware repository as event repository and the SPECjms_scenarioBase300 usage profile everything works.
Selecting the SPECjms_scenarioBase550 usage profile, which is a copy of the Base 300 model with increased frequence respectibely reduced interarrival time, eclipse is closed. The time until the crash happens is indeterminsitic. However, until now it happens always within 10 seconds. Looks like a concurreny problem with the increased workload.
Running PCM as a second instance results in the following stack trace in the console of the host eclipse while the PCM instance is closed automatically.
The SPECjms_model is attached.
Exception in thread "ProbeSpec Concurrent Blackboard" java.lang.RuntimeException: State could not be deserialized as it returned null values for state 0.
at de.uka.ipd.sdq.sensorframework.dao.file.entities.StateSerializer.deserialise(StateSerializer.java:46)
at de.uka.ipd.sdq.sensorframework.dao.file.entities.StateSerializer.deserialise(StateSerializer.java:1)
at de.uka.ipd.sdq.sensorframework.storage.lists.Chunk.loadChunk(Chunk.java:68)
at de.uka.ipd.sdq.sensorframework.storage.lists.Chunk.<init>(Chunk.java:35)
at de.uka.ipd.sdq.sensorframework.storage.lists.BackgroundMemoryList.ensureCorrectChunkLoaded(BackgroundMemoryList.java:111)
at de.uka.ipd.sdq.sensorframework.storage.lists.BackgroundMemoryList.add(BackgroundMemoryList.java:78)
at java.util.AbstractList.add(AbstractList.java:91)
at de.uka.ipd.sdq.sensorframework.dao.file.entities.StateSensorAndMeasurement.addState(StateSensorAndMeasurement.java:35)
at de.uka.ipd.sdq.sensorframework.dao.file.entities.ExperimentRunImpl.addStateMeasurement(ExperimentRunImpl.java:90)
at de.uka.ipd.sdq.pipesandfilters.framework.recorder.sensorframework.strategies.UtilisationWriteDataStrategy.writeData(UtilisationWriteDataStrategy.java:70)
at de.uka.ipd.sdq.pipesandfilters.framework.recorder.sensorframework.SensorFrameworkWriteStrategy.writeData(SensorFrameworkWriteStrategy.java:112)
at de.uka.ipd.sdq.pipesandfilters.framework.recorder.RawRecorder.processData(RawRecorder.java:48)
at de.uka.ipd.sdq.pipesandfilters.framework.PipesAndFiltersManager.processData(PipesAndFiltersManager.java:131)
at de.uka.ipd.sdq.simucomframework.calculator.SetupPipesAndFiltersStrategy$1.calculated(SetupPipesAndFiltersStrategy.java:42)
at de.uka.ipd.sdq.probespec.framework.calculator.Calculator.fireCalculated(Calculator.java:109)
at de.uka.ipd.sdq.probespec.framework.calculator.UnaryCalculator.execute(UnaryCalculator.java:36)
at de.uka.ipd.sdq.probespec.framework.calculator.Calculator.sampleArrived(Calculator.java:83)
at de.uka.ipd.sdq.probespec.framework.SampleBlackboard.fireSampleArrived(SampleBlackboard.java:189)
at de.uka.ipd.sdq.probespec.framework.SampleBlackboard.fireSampleArrived(SampleBlackboard.java:214)
at de.uka.ipd.sdq.probespec.framework.SampleBlackboard.addSample(SampleBlackboard.java:53)
at de.uka.ipd.sdq.probespec.framework.concurrency.ConcurrentSampleBlackboard.delegateAddSample(ConcurrentSampleBlackboard.java:39)
at de.uka.ipd.sdq.probespec.framework.concurrency.ConcurrentSampleBlackboard.access$2(ConcurrentSampleBlackboard.java:38)
at de.uka.ipd.sdq.probespec.framework.concurrency.ConcurrentSampleBlackboard$AddSampleAction.execute(ConcurrentSampleBlackboard.java:195)
at de.uka.ipd.sdq.probespec.framework.concurrency.ConcurrentSampleBlackboard$ProcessQueuedActions.run(ConcurrentSampleBlackboard.java:135)
at java.lang.Thread.run(Thread.java:680)
Environment
Operating System: MacOS X
Platform: Macintosh
Activity
I run the simulation in the weekend in a virtualized Windows and it worked.
I am not sure if the bug is caused by using MacOS, or if there is something wrong in my PCM installation. I will investigate this.
Using the provided model and simulation settings, I couldn't reproduce neither the Eclipse crash nor the NullPointerException (Windows 7, 64bit JVM). Have you changed any other simulation parameter?
And I'm also not convinced this issue is a concurrency bug: the blackboard being named ConcurrentBlackboard does only mean, that the simulation is decoupled from the facility that perists the measurements (I name it "ProbeSpec thread" hereafter). The decoupling is done by means of a queue: SimuCom simply puts each measurement in the queue and directly continues the simulation; the "ProbeSpec thread" gets the data from the queue, calculates measurements, and persists them. While SimuCom usually has more than one thread running in parallel, the "ProbeSpec thread" is the sole thread processing the measurements from the queue. The provided exception occured in this thread.
In very rare conditions, that thread could be started more than once, which is fixed now.
Attachment SPECjms.zip has been added with description: SPECjms Project