You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 21, 2022. It is now read-only.
A long in java is a 64bit signed integer, the max safe integer is roughly 2^63. In Javascript the max safe integer is roughly 2^53, thus those data types are not matching. For most variables of type long which are sent to the frontend this is no issue in practice because most long variables are incremented step by step - never reaching a number as big as 2^53.
However, trace IDs are generated by the Kieker framework as opposed to the ExplorViz Backend. Since Kieker should handle a lot of incoming traces from different sources, the IDs are not simply incremented. It exists a function in Kieker which maps incoming traces to a variable of type long. This function uses all 64 bits to practically avoid collisions of IDs and thus returns usually an integer which is larger than 2^53.
As a result trace IDs are not interpreted correctly by the frontend and result in colliding trace IDs. To fix this issue we need to either map the big trace IDs to smaller traceIDs in the backend or use a string representation for the trace IDs. The latter is to be preferred, since mapping would be more compute intense and error prone than converting to a string.
The text was updated successfully, but these errors were encountered:
A long in java is a 64bit signed integer, the max safe integer is roughly 2^63. In Javascript the max safe integer is roughly 2^53, thus those data types are not matching. For most variables of type long which are sent to the frontend this is no issue in practice because most long variables are incremented step by step - never reaching a number as big as 2^53.
However, trace IDs are generated by the Kieker framework as opposed to the ExplorViz Backend. Since Kieker should handle a lot of incoming traces from different sources, the IDs are not simply incremented. It exists a function in Kieker which maps incoming traces to a variable of type long. This function uses all 64 bits to practically avoid collisions of IDs and thus returns usually an integer which is larger than 2^53.
As a result trace IDs are not interpreted correctly by the frontend and result in colliding trace IDs. To fix this issue we need to either map the big trace IDs to smaller traceIDs in the backend or use a string representation for the trace IDs. The latter is to be preferred, since mapping would be more compute intense and error prone than converting to a string.
The text was updated successfully, but these errors were encountered: