Instancia _ Algoritmo circular de remplazo

[lag21392]

Hola que tal quería saber si en el algoritmo de remplazo circular de la instancia solo tengo que remplazar entradas atómicas o sigo haciendo como venia que remplazo de una entrada no atómica la primera parte y el resto lo libero, para posterior uso. Saludos.

[sebastianciancio]

Por enunciado, todos los Algoritmos de Reemplazo se aplican sobre entradas atómicas

[iago64]

Buenas buenas!

Efectivamente como comenta @sebastianciancio solo se reemplazan las entradas atómicas, las que no son atómicas van a quedarse ahí hasta que alguien les haga un STORE.

Saludos.-

[ricardoAguirreSanchez]

Buenas, una consulta de lo último que se menciona, un Store además de bajar a disco mi (clave,valor), también lo saca del storage?.

Saludos

[iago64]

Buenas! Así es, solamente lo sacas de la memoria, ya que el STORE, vendría a ser una especie de Guardame esta clave en disco que ya no la necesito operar

Saludos.-

[ricardoAguirreSanchez]

Claro, sabía que el Store me lo bajaba a disco, lo que no sabía era q ademas dejaba libre la entrada (o entradas) q estaban ocupando en el storage. Y lo mismo para el dump? Es decir con dump lo que hago es bajar toooodas las claves con sus respectivos valores a disco y dejo vacío mí storage? Esto podría ser un problema ya que al bajar siempre a disco, puede que termine teniendo más claves bajadas a disco de las que normalmente soportaría mí storage, es decir, si bajo la instancia y luego la trato de levantar, cuando esta quiera leer toooodas las claves q bajo a disco puede q sean más de las que soportaría el storage, no?

[iago64]

No señor, el dump solo resguarda la info en el disco por si llega a caerse la instancia ;), pero el contenido en la memoria no se toca. El dump lo podriamos ver mas o menos como hace word, sublime text o vscode que cuando lo cerras sin guardar te mantiene los cambios en algun lugar como para que vos no los pierdas.

Saludos.-

[ricardoAguirreSanchez]

Ah bien, gracias!

[ricardoAguirreSanchez]

Otra consulta, entonces si bajo una instancia y la vuelvo a levantar está solo debe reestablecer los archivos que guardo con la operación de dump, no de Store?

[iago64]

Deberías recuperar todas las claves que te diga el coordinador que tenias al momento de desconectarte (especialmente por si alguna entrada fue marcada como inválida mientras la instancia estuvo caída)

[sebastianciancio]

Que confusión esto!!!! Tenia entendido que un STORE sobre una key lo que hacia dentro de la Instancia es generar en el punto de montaje el archivo key.txt con su valor adentro (dump individual para la key)

Por otro lado, el DUMP lo que hace es "bajar a disco" toda la Tabla de Entradas en sus respectivos archivos .txt.

[iago64]

Sebas, estas en lo correcto, el store baja a disco el archivo key (no hace falta el .txt) y el contenido del archivo es el valor de la clave. El dump lo hace lo mismo pero para todas las claves en la instancia :)

La diferencia radica en que el STORE libera la clave mientras que el DUMP no.

[ricardoAguirreSanchez]

Entonces, resumiendo, el Store me baja a disco la clave y además deja ese espacio que ocupaba en el storage libre, y cuando una instancia se reconectar el coordinador le dice k claves tenía antes de desconectarse independientemente de tooodos los archivos k la instancia pueda ver en su Punto de montaje, es así?

[iago64]

Exactamente, digamos que es un buen resumen de todo el issue :)

[ricardoAguirreSanchez]

Ahora, entonces si una instancia hace correctamente un Store, significa que el coordinador tendría que sacar de sus registros la <instancia,clave> , ya que en teoría esa clave ya no está más en la instancia sino que está bajada a disco?

[natoszme]

Supongo que no hace falta: si hacés un set, la crea de vuelta. Y si hacés otro store, tiraría error por clave inexistente

[friends96]

y al momento de levantar instancia en caso de que se haya caido previamente, como se cuales claves estaban storeadas y cuales no, cuales vuelvo a poner en la tabla de entradas? hasta ahora habiamos entendido que solo se saca de TablaEntradas a las clavesAtomicas que fueron pisadas por otras mas nuevas en el binario. No que tambien se sacaban a las Storeadas

[LeaTex]

Yo creo que deberíamos dejar de hacer consultas, porque cada vez que preguntamos algo nos aparece una nueva funcionalidad que no estaba especificada.

Me parece que los analistas no hicieron bien el relevamiento inicial, y se me está activando la matriz de riesgos, ya no puedo mitigar más, y el proyecto está sufriendo una demora de 4 semanas en los tiempos de entrega.

Voy a tener que pedirle a los desarrolladores que trabajen horas extras para cumplir con el hito.

Nosotros estamos con la lógica de: DUMP = STORE masivo

STORE clave: Persiste el valor de la clave asociada en un archivo dentro de la Instancia. Por cada clave persistida se generará un archivo particular conteniendo el valor en texto plano. Esta operación también debe liberar el bloqueo sobre la clave.

Ahí no habla de liberar la memoria ni nada. El tema del bloqueo lo maneja el Planificador, así que el Coordinador y la Instancia ni enterados.

Por otro lado, si cada STORE implicara liberar la memoria, no tendrían (mucho) sentido los algoritmos de reemplazo, porque cualquier entrada guardada en disco me dejaría un "hueco" en la memoria que me permitiría mantener los nuevos valores sin tener que reemplazar (casi) nada.

Por nuestra parte vamos a seguir por el camino que ya traemos, porque este cambio de alcance nos complica todo, y tenemos que volver a tocar temas que ya habíamos cerrado.

[iago64]

Buenas, buenas? Vamos por partes, porque este issue se diversifico de una manera increible.

@natoszme ojo que el que crea claves es get y no set, el set te vuela por los aires cuando no existe la clave.

@acerbonimartin cuando reconectas una instancia deberia ser el coordinador el que te diga que claves tenias previamente a tu desconexion.

@LeaTex no te prepcupes, liberar o no la memoria afecta entre nada y las chances de que argentina no se cruce con nigeria en fase de grupos, ya que el reemplazo de entradas y compactacion muy posiblemente va en un test puntual donde estoy pensando en probar un caso muuuy acotado y con solo un par de entradas, de paso les dejo un pequeño spoiler de que van a levantar el tp con 1 sola instancia y de entradas chicas (para que sea facil y rapido de verifiar). Por cierto no se alarmen porque las pruebas finales las tengo en semi alpha, y posiblemente en 15 dias (ya que quiero tener algo de feedback del sabado) tenga cerrada la estrategia completa para que no sean 2 años de pruebas en el labo (como ya nos paso muuuchas veces)

Saludos.-

[sebastianciancio]

Mi duda sobre estas definiciones es que no están en el enunciado del TP. Van a sacar una fe de erratas?

[LeaTex]

@iago64 joya, nos quedamos más tranquilos.

[tferraro]

Permisoooo, vengo a parar la :soccer:

Esto que dice @LeaTex, como dijo dami:

Nosotros estamos con la lógica de: DUMP = STORE masivo STORE clave: Persiste el valor de la clave asociada en un archivo dentro de la Instancia. Por cada clave persistida se generará un archivo particular conteniendo el valor en texto plano. Esta operación también debe liberar el bloqueo sobre la clave.

..es correcto, porque cuando @iago64 cuando dijo

La diferencia radica en que el STORE libera la clave mientras que el DUMP no.

...lo que quiso decir fue que te "libera" la entrada no-atomica, porque mueren con el sistema cuando se cae. Lo hablé con el y fue un comentario mal redactado nomás.

Entonces:

• DUMP = STORE Masivo, YES.
• El STORE no libera claves, solo las baja a disco. ~- Las entradas no-atomicas no se pueden regenerar.~

:wave:

Update: Por las mosscas, como para atajar una posible pregunta, sobre el DUMP = STORE Masivo, guarda que el DUMP no libera los bloqueos. Update2: No le den bola a lo que taché, lo escribí pensando en otra cosa y escribí regenerar en vez de reemplazar :see_no_evil:

[bengalaq]

La conclusión del issue sería:

• DUMP: Baja claves de la instancia a disco cada cierto intervalo de tiempo, con el fin de poder reconectar la instancia al sistema. NO LIBERA ENTRADAS NI CLAVES.
• STORE: Baja claves de la instancia a disco. LIBERA CLAVES. NO LIBERA ENTRADAS EN LA INSTANCIA.

¿Estoy en lo correcto?

[tferraro]

@Jaugustopose eso!

[natoszme]

@iago64 claro. Pero supongamos que una clave se reemplazó en una instancia y el esi ya le hizo GET. Cuando se va a hacer SET, el coordinador (al menos por ahora en nuestro tp) no se entera que esa clave fue reemplazada entonces le manda la instrucción a la misma instancia que la reemplazó. La instancia entonces, por las cuestiones de disponibilidad mencionadas en el enunciado, crea la clave de vuelta y la setea. Eso está ok?

Si me lo decías porque no se puede hacer un set directo, en nuestro tp el esi tiene que tener él la clave bloqueada para poder hacerlo. Así que si no se hizo un get antes (que hace que exista en el sistema), no se va a poder hacer el set. Te aclaro todo esto para validar.

Abrazo!

[iago64]

@natoszme EXACTO! cuando vuelvas a hacer un SET, vas a tener que crear la clave en la instancia nuevamente (y si hace falta reemplazas una pre-existente) Me quedo más tranquilo con lo de que el ESI tiene que haber hecho GET antes, no aclare nada que no estuviera claro desde antes entonces :)

Abrazo!

[natoszme]

Claro. Gracias @iago64 !

[santiluccadeguevara]

Una cosita más súper colgada (para dar acto de presencia... (?)): en el reemplazo puede ocurrir que se necesite reemplazar más de una clave atómica?

Ejemplo de Script (Con una Instancia de 2 entradas de tamaño 1, con el algoritmo circular comenzando desde la primer entrada):

GET A
GET B
GET C
SET A, X  // Ocupa la primer entrada con el valor de A
SET B, Y  // Ocupa la segunda entrada con el valor de B
SET C, ZZ // Reemplaza las dos primeras entradas (A y B) para meter C

¿El algoritmo debería reemplazar, además de la clave A, también la B para meter C?

No quería quedarme afuera XD Gracias por las aclaraciones. Saludos.

[iago64]

Buenas buenas! Si, deberias reemplazar las 2 entradas para que entre el valor de la clave C. Saludos.-

[AlejoZito]

@tferraro

Entonces: DUMP = STORE Masivo, YES. El STORE no libera claves, solo las baja a disco.

• Las entradas no-atomicas no se pueden regenerar.

@Jaugustopose

La conclusión del issue sería:

DUMP: Baja claves de la instancia a disco cada cierto intervalo de tiempo, con el fin de poder reconectar la instancia al sistema. NO LIBERA ENTRADAS NI CLAVES. STORE: Baja claves de la instancia a disco. LIBERA CLAVES. NO LIBERA ENTRADAS EN LA INSTANCIA.

¿En que quedamos?

[iago64]

@AlejoZito que tal?

Es un problema de que usamos palabras similares (por no decir iguales) para cosas que no son lo mismo.

El STORE te libera el bloqueo o retención de la clave por parte de un ESI. (Es el efecto contrario al GET) el STORE NO te libera la/las entradas que tenga ocupadas esa clave en la instancia.

Saludos.-

[tferraro]

@AlejoZito, por eso el thread tiene un orden de comentarios😛. En la primera habla de ‘liberar’ claves, como eliminarlas, osea, lo que en el segundo denomina como liberar entradas, que es la terminologia mas apropiada. Por eso @Jaugustopose pidio aclararlo😁.

Es solamente un tema de semantica, mala mia🙈.

[AlejoZito]

Gracias por la aclaración!

[iago64]

Genial, a todo esto nos olvidamos del owner original del issue, @lag21392 te queda alguna duda?

[lag21392]

Una duda mas, si el STORE no borra las claves de la matriz de entradas, en que momento se generan huecos para que la compactación tenga sentido.

[iago64]

La prueba es bastaaante facil de hacer y se hace teniendo una clave que ocupa 2 entradas y con el siguiente SET se hace ocupar 1 :)

Ej rapido instancias con 5 entradas de tamaño 5: SET clave1 Sabado (el valor ocupa 6 por ende 2 entradas) SET clave2 Sueño (el valor ocupa 5)

si en tu instancia te quedaron las entradas: e0: clave1 e1: clave1 e2: clave2 e3: NULL e4: NULL

y haces SET clave1 hola (el valor ocupa 4, por lo tanto la segunda entrada la tienen que liberar)

te debería quedar: e0: clave1 e1: NULL e2: clave2 e3: NULL e4: NULL

y ahi si podrias compactar. Saludos.-

[lag21392]

Gracias saludos.