[GELÖST] Bitte Hilfe, die RM spinnt voll ("Already in map!" ERROR)

[jmaus]

Nach welcher Vergabestrategie ermittelst du denn nun die nächste freie ISE-ID ?

Erste Strategie ist, keine freie zu Suchen sondern wenn möglich immer jetzt höchste_id+1 zu machen, danach aber zu checken ob die frei ist oder nicht. Wenn nicht oder wenn +1==ISE_ERR dann suche nach freier ID.

Das ursprüngliche Problem war aber doch nicht die alte vergabe strategie, sondern die objektliste wird dynamisch bei einer grenze von 30000 um weitere 30000 freie einträge erweitert und hier gab es eine stelle die zwar aber um weitere 30000 vergrößert hatte, dann aber das neue objekt direkt (auch wenn dieses eine id < höchste_id hatze) gabz oben in der liste hinzugefügt hatte und damit die ordnung durcheinander gebracht hatte. Das ist jetzt nun beseitigt und eben zusätzlich die vergabe neuer ids noch abgeprüft ob diese noch frei ist um 100% sicher zu gehen.

[Black]

Kommt denn diese regel

Wenn nicht oder wenn +1==ISE_ERR dann suche nach freier ID

Überhaupt über ID_ERROR hinaus ?

Black

[jmaus]

Kommt denn diese regel

Wenn nicht oder wenn +1==ISE_ERR dann suche nach freier ID

Überhaupt über ID_ERROR hinaus ?

Wie genau meinst du das?

[Black]

Ich meinte, unter welchen Bedingungen vergibt der Algotithmus denn dann eine ID grösser als 65535 ?

Wenn ich den Ansatz richtig deute, sorgt die Testung ID==ID_ERROR, dann finde Freie ID dafür,

dass dieser Algorithmus dann in dem vorhandenen Bereich eine Lücke sucht, also wieder im Niedrigen Bereich anfängt die erste freie Nummer zu suchen.

Ich lass grad mal vom SDV ein paar tausend Programme Synthetisch anlegen, mal schauen, was er an der Grenze von 65535 machen wird....

Asso ich habs nun getestet...

3033 angelegte Programme.
die IseID lief dabei über die ID_ERROR Marke drüber

Interessant ist das Markierte Programm, dessen Interne Objekte Nun die Grenze knacken.

Nach einem Reboot eine Systemvariable neu angelegt.

DIese wird nun oben als höchste neue Nummer erzeugt. der Mechanismus scheint nicht zu versuchen, freie Lücken aufzufüllen.

MapError3.PNG (18.23 KiB) 511 mal betrachtet

In der Rega selber hätte es dabei noch genügend freien Platz gegeben.

Code: Alles auswählen

------------------------------- Scriptausgabe -------------------------------
1392	-	1427
1429	-	1476
1479	-	1711
1714	-	1724
1726	-	1737
1739	-	1808
1811	-	1880
1883	-	1952
1955	-	2024
2027	-	2144
2146	-	2183
2257	-	2258
2267	-	2269
2278	-	2481
2484	-	2570
2573	-	2684
2686	-	2789
2798	-	2855
2864	-	2867
3065	-	3249
3253	-	3258
3267	-	3354
3357
3360
3361	-	3375
3377	-	3407
3416	-	3418
3427	-	3429
3438	-	3440
3452	-	3476
3478	-	3567
3574	-	3660
3662	-	3691
3694	-	3727
3736	-	3843
3852	-	3931
3942	-	3957
3966	-	3980
3988	-	4063
4072	-	4073
4078	-	4194
4202	-	4243
4256	-	4303
4325	-	4463
4465	-	4590
4645	-	4798
4846	-	4943
4952	-	4953
4958	-	4980
4983	-	5407
5420	-	5434
5454	-	5596
5608	-	6490
6493	-	6500
6509	-	6549
6552
6558	-	6799
7039	-	7053
7062	-	7063
7100	-	7176
7191	-	7960
7969	-	8272
8429	-	8444
8449	-	8460
8463	-	8485
8498
8501	-	8669
8673	-	9542
9553	-	9618
9622	-	9632
9641	-	9726
9734	-	9845
9858	-	9930
======================================
Anzahl der Lücken  : 73
Freie IDs in Lücken: 7432
Grösste Lücke      : 884

Black

[jmaus]

DIese wird nun oben als höchste neue Nummer erzeugt. der Mechanismus scheint nicht zu versuchen, freie Lücken aufzufüllen.

Genau so ist es und so habe ich es auch versucht zu beschreiben. Ich sagte ja, er macht per default jetzt einfach immer +1, prüft aber nun zusätzlich ob das zu einem Konflikt führt.

In der Rega selber hätte es dabei noch genügend freien Platz gegeben.

Genau so ist es. Ist aber auch total egal das da jetzt lücken sind. Ordnung in DatenbankIds zu haben wollen nur Spieser nur wenn er wieder auf die 65535 oder an die maximale grenze von 2^31 stoßen wird, wird er wieder nach lücken sichen. Ansonsten passiert jetzt einfach immer +1 bis ans Ende von 2^31. Also praktisch gesehen wird das also nun nie wieder passieren in deiner restlichen Lebenszeit

[MichaelN]

Also praktisch gesehen wird das also nun nie wieder passieren in deiner restlichen Lebenszeit

Black, das sollte doch wohl Ansporn genug sein dein Programm bis an die Grenze zu treiben.

[jmaus]

Also praktisch gesehen wird das also nun nie wieder passieren in deiner restlichen Lebenszeit

Black, das sollte doch wohl Ansporn genug sein dein Programm bis an die Grenze zu treiben.

Ich meinte natürlich auf einer normalen produktiven CCU Umgebung in normalen Nutzungsszenario…

[Black]

Black, das sollte doch wohl Ansporn genug sein dein Programm bis an die Grenze zu treiben.

Nichts leichter als das ^^...

// Hinweismodus ein

Also man lege z.b. eine Sysvar an, mit der ID 2147483646 (zur Erinnerung 2^31= 2147483648)

dann erzeuge man eine Neue Sysvar:
diese wird brav die ID haben ? richtig: 2147483647

Dieses ist auch das Limit zu 2^31-1

nun sind wir gemein, und erzeugen nochmal eine Sysvar...
er sucht keine Lücke sondern: die ID wird Negativ !

Map10.PNG (6.23 KiB) 362 mal betrachtet

Im ersten Moment harmlos,
das Bäng Potential hier an der Border besteht in Schleifen, die dann keinen sinnigen Abbruch finden

Code: Alles auswählen

n=1;
while (n<= obj.ID() ) {

n=n+1;
}

oder:

Code: Alles auswählen

string s= system.GenerateEnum(0, -4);  

ergibt einen Leerstring und keine Aufzählung.

// Hinweismodus aus

Black

[MichaelN]

Sieht aus als müsste Jens da nochmal ran. Oder sein Enkel...

[jmaus]

Sieht aus als müsste Jens da nochmal ran. Oder sein Enkel...

Genau so sehe ich es. Faktisch hat das keinerlei praktische Relevanz.