Menu
▾
▴
vishnu-developers — dedicated to vishnu development issues. design, architecture and roadmao
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(12) |
Nov
(20) |
Dec
(13) |
|---|
|
From: <her...@gm...> - 2005-12-08 14:52:14
|
barbaro marian On 12/8/05, Mariano Tepper <mar...@fi...> wrote: > > 8/12/05 11:24 > Anda el problema con los usuarios y los nombres de tablas ( > username.tablename). > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.1.371 / Virus Database: 267.13.12/194 - Release Date: > 07/12/2005 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Vishnu-developers mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/vishnu-developers > |
|
From: Mariano T. <mar...@fi...> - 2005-12-08 14:28:11
|
8/12/05 11:24 Anda el problema con los usuarios y los nombres de tablas (username.tablename). -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.371 / Virus Database: 267.13.12/194 - Release Date: 07/12/2005 |
|
From: Mariano T. <mar...@fi...> - 2005-12-05 15:02:58
|
Probe la paginacion desde el cliente y anda... Carga la 2da pagina, anda el tema de las sesiones por thread... Tuve que tocar alguan cosita el el PageManager, asi que hay que reconstruir los stubs. Saludos, Mariano -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.12/192 - Release Date: 05/12/2005 |
|
From: Mariano T. <mar...@fi...> - 2005-12-03 14:06:51
|
Puede ser singleton porque registra propiedades de threads, asi que no jode que sea unica para la VM. Fijate que hice una clase en un nuevo paquete que se llama threading. >Date: Sat, 03 Dec 2005 11:01:14 -0300 >To: Vishnu-developers >From: Mariano Tepper <mar...@fi...> >Subject: Threads & Sessions revisited > >Tal vez en vez de un mecanismo de suscripcion, deberiamos usar una clase >singleton que maneje el ThreadLocal. Esto es porque la API no garantiza >que el thread que recibe la notificacion, sea el mismo que la envia... En >la practica, usa el mismo thread, pero... > >"The order in which notifications will be delivered is unspecified. The >default implementation provided in the Observable class will notify >Observers in the order in which they registered interest, but subclasses >may change this order, use no guaranteed order, deliver notifications on >separate threads, or may guarantee that their subclass follows this order, >as they choose. " -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.11/191 - Release Date: 02/12/2005 |
|
From: Mariano T. <mar...@fi...> - 2005-12-03 14:04:06
|
Tal vez en vez de un mecanismo de suscripcion, deberiamos usar una clase singleton que maneje el ThreadLocal. Esto es porque la API no garantiza que el thread que recibe la notificacion, sea el mismo que la envia... En la practica, usa el mismo thread, pero... "The order in which notifications will be delivered is unspecified. The default implementation provided in the Observable class will notify Observers in the order in which they registered interest, but subclasses may change this order, use no guaranteed order, deliver notifications on separate threads, or may guarantee that their subclass follows this order, as they choose. " -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.11/191 - Release Date: 02/12/2005 |
|
From: Mariano T. <mar...@fi...> - 2005-12-03 12:32:36
|
Hernan, La opcion que veo mas potable para resolver el problema de threading es=20 usar la clase ThreadLocal, registrar los threads con su session id en algun= =20 momento oportuno. Luego, usar la info de esa clase. Ese momento oportuno,=20 existe. Tanto para los pedidos remotos, como para los threads del service=20 (obviamente, porque se esta haciendo). La gran pregunta es donde meter eso= =20 con elegancia mediana para los threads RMI. El lugar oportuno para setear=20 la id del thread es en el pagemanager: no esta bueno tener manejo de=20 threads en esta clase. Ideas: 1) usar algun mecanismo de publicacion/suscripcion como habias sugerido en= =20 el mismo pagemanager 2) hurgar para ver si lo podemos esconder en alguna clase en el marco del=20 paquete de paginacion. Posible sugerencia no analizada con profundidad: en= =20 el metodo SetPage del PagingContext. Tambien se podria usar=20 publicacion/suscripcion. Ademas de eso, habria que controlar la serializaci=F3n de cada pagina,=20 mediante externalizacion, para asegurarse en ese momento, que los registros= =20 pueden ser leidos por el cliente solicitante. (Esto lo habiamos charlado,=20 pero lo escribo para que quede registrado en algun lado) Esto nos evita=20 tener que agregar un select cuando el comando sql es SELECT * FROM ... (sin nada en el where). No tengo nada muy concreto, pero me parece la punta mas rescatable, sobre=20 todo la opcion 2 Saludos, Mariano -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.10/190 - Release Date: 01/12/2005 = |
|
From: <her...@gm...> - 2005-12-03 05:04:44
|
marian, estuve buscando otro rato sobre el problema de las sesiones en internet encontre un post en news que discute el problema que tenemos con las sessions en RMI. lo pego a continuacion por si tenes curiosidad. SK, Read below!!! Steven Owens wrote: > Yet another idea that never made it to the top of my "to-do" list > was to hide the whole RMI-ness of it so the servers would seamlessly > switch from using local calls to RMI calls, depending on whether they > were running under the same JVM or not. I couldn't think of an > elegant way to handle it at first, but I arrived at the idea of having > a singleton connection factory. On startup each server would register > with the registry and stuff a local reference to itself into the > factory. Then the factory would return either a local reference if it > had one, or get an RMI reference. I never did work out all the > details. Does this sound like a good idea? I got that implemented. I have a service interface called Reflector, which is a Reflection API to reach java objects through the use of dot-notation String names, such as App.MainContainer.PresentValues['23'].Profit.Value Since that service is pretty handy, I have a RemoteReflector interface is t= he same but also throws RemoteExceptions. Both the RemoteReflectorImpl and ReflectorImpl implements the Reflector interface, and the Connection factory (connection is estabilshed by connection strings) returns the local reference (if ound within the same JVM) or the remote reference, but the client always cast to the Reflector interface. > > Not so easy approach... > > > Create your own SocketFactory, Client and ServerSockets, which will > > either upon Connect, or explictily requested and set by the client, > > negotiate a session object or ID. And this session object is sent > > along in each following request, not visible to the client code. > > > The server side could use the ThreadLocal system to place the > > session object available to all parts of the code that are part of > > the execution path without changing existing method signatures. (Why > > have I not thought about that before?) > > Or it's quite possible I'm not understanding what you wrote. > Care to elaborate? I am not sure what I meant. It was a spur of the moment, and got carried aw= ay with the ThreadLocal idea. I presume it could be a possibility where you have cemented interfaces, tha= t can not change, but where Session information is needed in later upgrades. = It just struck me at that time, that ThreadLocal may be used to extend the interface without breaking compatibility in those interfaces. Sessions management part II. The Client request a Session object, which in fact is a remote object, and = all session based requests go through this RMI object, instead of directly to t= he service object. EASY! I am also not very accustomed with Sessions as a concept. I prefer stateles= s requests, where anything may happen asynchronous and where connections may = be lost and reestablished without any implications of server complexity. Niclas |
|
From: <her...@gm...> - 2005-12-03 04:24:48
|
---------- Forwarded message ----------
From: Hern=E1n Rancati <her...@gm...>
Date: Dec 3, 2005 1:24 AM
Subject: news
To: Mariano Tepper <mar...@fi...>
continuo, pero brevemente.
encuentro algunas soluciones, todas algo pobres:
1- colocar la info de sesion en los objetos que trabajan
con remoting para poder identificar futuros pedidos en el
servidor.
2 - Notificar la informacion de la sesion al llegar al servidor para que lo=
s
ShareGates puedan saber quien pregunta. Algunas posibilidades:
A - notificar la sesion al Service (usamos una session thread local e=
n
service) y el sharegate le pregunta al service
B - notificar la sesion a la clase ShareGate y esta tiene una session
thread local estatica.
Hernan.
|
|
From: <her...@gm...> - 2005-12-03 03:52:49
|
Mariano, estuve pensando un buen rato sobre el problema del locking al traer el resto de las paginas de un recordset al cliente. tengo algunas consideraciones no muy prometedoras que hacer. 1 - sobre las operaciones de cada cliente: Cada vez que un cliente envia una operacion, como el curso de la operacion es determinado en parte por la sesion asociada al cliente (por ejemplo puede evitarse un bloqueo si la sesion es quien tiene el acceso al recurso a un recurso pedido), es necesario que la informacion de sesion llegue implicita o explicitamente al servidor con cada pedido. A modo de ejemplo, te recuerdo el estado actual del pedido de comandos al service. Estos comandos tienen la informacion de sesion dentro (explicitamente). Luego, el resto del motor trabaja con la informacion de sesion implicitamente (guardada en los threads del service y accesible desde el current thread). El asunto esta entonces cuando llega un pedido que no pasa por el service y se resuelve como una llamada simple a un metodo de una interfaz (con una llamada RMI). En estos casos, no viaja un comando por lo que la informacion de sesion no es explicita, ni hay un thread asociado a la sesion del lado del servidor (y entonces tampoco es implicita). Casos en los que sucede esto son Page y Record si no me equivoco. De esto veo un par de salidas: A- Page y Record tendran que tener informacion explicita de sesion B- hay que deducir esto de informacion relativa a RMI / ip+port? sigo en otro mail. |
|
From: <her...@gm...> - 2005-12-03 01:28:33
|
marian, si andas cerca de la computadora mas tarde, conectate a ver si le encontramos la vuelta al problema del bloqueo del resto de las paginas. Estuve pensando un rato al respecto y no se me ocurre nada elegante. hernan. |
|
From: Mariano T. <mar...@fi...> - 2005-12-01 19:22:19
|
Agustin, Gustavo y Juan Pablo: ahora que ya paso el parcial estaria bueno que se pongan con las tareas de documentacion. Asi esta lista unos dias antes de la entrega. Cualquier cosa escriban. Saludos, Mariano -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 30/11/2005 |
|
From: <her...@gm...> - 2005-12-01 14:11:16
|
caso de test para usar en multi threading (actualmente no funciona): UPDATE clients SET name=3D'mht' WHERE id=3D32 hernan. |
|
From: <her...@gm...> - 2005-12-01 12:31:15
|
hola marian, en que estado esta el motor? ayer hice un update pero me termine yendo a dormir despues de garrapatear un par de lineas. Que tenemos pendiente? hernan! |
|
From: Mariano T. <mar...@gm...> - 2005-11-26 23:09:18
|
SOLUCIONADOS >Lista de problemas: > >1) problema de sincronizacion con el deadelockdaemon, ahora esta >deshabilitado. Repensar si hay una mejor forma de hacer sin usar otro thread... > >2) problema de sincronizacion con el rollback de transaccciones... no se >que carajo esta pasando, no me doy cuenta. Levanten el motor y hagan lo >siguiente: > INSERT INTO clients VALUES (100.0,'mht') > ROLLBACK TRANSACTION >Va a saltar un problema de sincronizacion en el Transaction terminator. >Otra cosa que NO entiendo es porque al sharemanager llegan 2 >notificaciones cuando mandas un releaseAccessForRead. > >Yo estuve horas debugeando, agregue un millon de synchronize, pero no veo >el problema ni, obviamente, la solucion. > >Saludos, Mariano > > >-- >No virus found in this outgoing message. >Checked by AVG Anti-Virus. >Version: 7.1.362 / Virus Database: 267.13.7/182 - Release Date: 24/11/2005 > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Vishnu-developers mailing list >Vis...@li... >https://lists.sourceforge.net/lists/listinfo/vishnu-developers > > > >-- >No virus found in this incoming message. >Checked by AVG Anti-Virus. >Version: 7.1.362 / Virus Database: 267.13.7/182 - Release Date: 24/11/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: 25/11/2005 |
|
From: Mariano T. <mar...@fi...> - 2005-11-25 20:06:08
|
Lista de problemas: 1) problema de sincronizacion con el deadelockdaemon, ahora esta deshabilitado. Repensar si hay una mejor forma de hacer sin usar otro thread... 2) problema de sincronizacion con el rollback de transaccciones... no se que carajo esta pasando, no me doy cuenta. Levanten el motor y hagan lo siguiente: INSERT INTO clients VALUES (100.0,'mht') ROLLBACK TRANSACTION Va a saltar un problema de sincronizacion en el Transaction terminator. Otra cosa que NO entiendo es porque al sharemanager llegan 2 notificaciones cuando mandas un releaseAccessForRead. Yo estuve horas debugeando, agregue un millon de synchronize, pero no veo el problema ni, obviamente, la solucion. Saludos, Mariano -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.7/182 - Release Date: 24/11/2005 |
|
From: <her...@gm...> - 2005-11-25 04:49:25
|
mariano, agregue el puenteo de la exception al cliente. Funciona para el primer error pero no para los siguientes, tengo q averiguar la causa. Sospecho que puede tener q ver que haya quedado un thread muerto en el service, hay q sacarlo y poner uno nuevo. saludos, hernan. |
|
From: Mariano T. <mar...@fi...> - 2005-11-22 02:18:54
|
Descubri porque no andaba el locking... No estaba usandose!!! :) Hay que enganchar las clases en algun lado... Saludos, Mariano -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.4/176 - Release Date: 20/11/2005 |
|
From: <her...@gm...> - 2005-11-21 18:28:22
|
hola gente, para correr el motor hace falta: - regenerar los stubs RMI - regenerar el parser - borrar la carpeta tables - crear el archivo "properties.id <http://properties.id>", conteniendo la linea "id=3D0" hernan. |
|
From: Mariano T. <mar...@fi...> - 2005-11-21 04:20:38
|
Ahora el motor maneja un solo tipo de excepcion: VishnuException. La clase= =20 esta en el paquete vishnu, pero esta hecha como la mierda... Acepto=20 sugerencias para hacerla bien. Eso trajo como consecuencia que tuve que tocar los tests para que anden con= =20 un solo tipo de excepcion. Ma=F1ana 22/11/05 termino los statements, que hoy no tuve tiempo. Cuestiones abierta: - capturar las excepciones de persistencia, apagar el motor y prenderlo con= =20 recovery. - cuando, donde y como, ir poniendo nuevos safepoints en el log. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.4/175 - Release Date: 18/11/2005 |
|
From: Mariano T. <mar...@fi...> - 2005-11-20 22:36:09
|
- Cambie unas cuantas cosas para que ande el tema de userName.tableName. Ya anda. - Tienen que rearmar los stubs porque el pagemanager tenia un error. - Voy a seguir revisando el tema de las excepciones, el tema del comportamiento del motor frente a fallos de presitencia y voy a armar los statements/performers que faltan Saludos, Mariano -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.362 / Virus Database: 267.13.4/175 - Release Date: 18/11/2005 |
|
From: <her...@gm...> - 2005-11-19 15:41:45
|
che, mirate http://vishnu.sourceforge.net esta la arquitectura y la API del javadoc con sus diagramas UML, mirate los UML de las clases, se puede navegar de diagrama en diagrama. saludos, Hernan! |
|
From: <her...@gm...> - 2005-11-16 02:53:02
|
cuidado, hay que generar las interfaces remotas para que funcione: -abrir build.xml -ir a vista outline -run sobre generateRemotingStubs o algo asi. hernan |
|
From: <her...@gm...> - 2005-11-16 02:48:38
|
detalle, al final use los Future de java, cambie el nombre de ExecutionServices a Response, quedo algo asi: Future<Response> perform(Command c); para resolver el tema de las RemoteException (a medias) hice un adaptador y este lo usa el Remoting, quedo entonces: RemoteFuture<Response> perform(Command c) hernan! On 11/15/05, Hern=E1n Rancati <her...@gm...> wrote: > > Marian, > > hice andar correctamente el pooling y el transporte. Deje 4 threads > habilitados, > hay que empezar a mandar cosas de diferentes sesiones a ver como revienta= . > > hernan. > > ps: si podes, conectate. > > |
|
From: <her...@gm...> - 2005-11-16 02:44:54
|
Marian, hice andar correctamente el pooling y el transporte. Deje 4 threads habilitados, hay que empezar a mandar cosas de diferentes sesiones a ver como revienta. hernan. ps: si podes, conectate. |
|
From: Mariano T. <mar...@fi...> - 2005-11-14 13:57:46
|
Hernan, con los ultimos cambios que hiciste, no anda mas el motor. Estuve
rastreando el error y lo encontre.
Cuando vos le haces estas llamadas al SQLCommand, desde los diferentes
RelationalServices:
sqlCommand.setContext(context);
sqlCommand.setRelationContext(relationContext);
ninguno de los dos contextos ni es remoto, ni es serializable. No te
olvides que el objeto sqlCommand es remoto ("vive" en el cliente).
El problema es que serializarlos es una locura, y hacerlos remotos, me
parece feo tambien.
Voy a ver si se me ocurre alguna solucion...
Saludos, Mariano
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.362 / Virus Database: 267.13.0/167 - Release Date: 11/11/2005
|
