Hi Jacques and list, After playing for almost 2 weeks with the entity sync feature I've come up with the conclusion that it still needs some work to get ready for production environment. Currently it is unreliable, and useless :(
- There is a bug in the design. The MCS remembers the sync status and currently reached sync timestamp for each client. This is not a good approach imho. Why ? The client asks the server: have you got something for me ? Next: The MCS checks the last successful sync timestamp for that particular client and selects the entities that should be passed to the client. After successfully transferring the entities to the client over RMI the MCS assumes that the sync is successful and updates the last successful sync timestamp. The problem is that the client does not confirm the success of the operation. If for some reason the client is unable to update the entities ( either shutdown, power failure, DB error or whatever ) the MCS isn't aware of that and the next sync will not include the missed entities. There is no way to fix the skipped entities but re-creating the client's database from zero. That is the main issue actually. It could be easily solved however. The most easy ways are: 1) The client will remember the sync timestamp and will include it as an argument when asking the server for pull sync. This way the client will update the last successful sync timestamp after storing each entity. The server does not have to remember anything regarding the client's sync status. 2) After each sync session the server will wait for confirmation from the client before updating the last successful sync timestamp. If not updated than the sync process is considered to be unsuccessful and the timestamp will not be updated. I personally prefer approach 1) as in case of network error, power failure or whatever error the sync process will continue from the place it has stopped. - There are some swallowed exceptions. If a network problem occurs during the sync process the server's status remains "sync running" and the client is not able to sync anymore until the status is reset by an operator. - The last issue is the performance. Using RMI is an easy approach from developer's perspective but it is very very slow. I had a database with 5000 products. The initial sync took about 2 hours. The hardware is pretty good, the network connection between the MCS and the client ofbiz is about 50 mbits. What if we have 100 000 sales per day ? The sync process will take probably the entire night :) Here I would suggest transferring GenericEntity instances over RMI to be removed. Instead a regular XML could be used. Either over RMI or SOAP - does not matter. So in general the picture would be: 1) Server does not remember any timestamp for any client. 2) Client calls the pull entity sync RMI ( or soap ) method and passes the entity sync ID and the timestamp of the last successful sync as arguments. Including the timezone of course :) 3) The server generates an XML file for all the entities in that entity sync group using the timestamp provided by the client. 4) Client starts updating the entities described in the received XML line by line. After each entity is updated successfully the timestamp is also updated ( on the client side - the server does not remember any client timestamps ). 5) If a failure occurs in the middle of the update process what we'll have is a sync process completed to like 50%. With the correct timestamp. When the next sync job starts the client will use the timestamp and the server will generate a new XML from the place the sync has failed. Of course an optimization could be used - the XML will be stored in a new db table so the client can continue storing the entities without asking the server to generate something he has already done. Some improvements that could be also useful: 1) The client ofbiz instances have sequence-id-prefix. So when the server is accepting push syncs it could also check the prefixes of the PKs and disallow entities without the correct prefix in the primary key. That's just a cheap insurance against errors :) We don't want store A to make sales on behalf of store B just because somebody made an error while configuring the pos ofbiz instance. 2) A time synchronization mechanism could be also implemented. In general when syncing there is a requirement that the server's and client's clocks are in sync ( ntp ). We don't want to set the system clock in ofbiz, but we could implement a check if the clocks are in sync and refuse to start the synchronization in certain cases. 3) A new column could be added to all the entities: isFromEntitySync : flag. This way we could avoid cases in which the client is trying to push records to the server which were actually pulled by the server. Yes, I know the entity's created timestamp should help us avoid such cases, but when the sync process is interrupted things like that could happen. Otherwise for our current project we've implemented a DB level synchronization - using triggers for INSERT, UPDATE and DELETE and a stored procedure which syncs the clients with a MCS. It works much ( tens of times ) faster than ofbiz entity sync . But it is DB dependent. So after getting comments and suggestions to this e-mail I would like to invest some time in fixing all those issues with the ofbiz entity sync and switch to it when it's ready :) Thanks for your time, Deyan -----Original Message----- From: Jacques Le Roux <jacques.le.r...@les7arts.com> Reply-to: "Jacques Le Roux" <jacques.le.r...@les7arts.com> To: user@ofbiz.apache.org Subject: Re: EntitySync RMI error Date: Sun, 27 Sep 2009 17:02:57 +0200 Hi Deyan, It would be very valuable if you could post an article on wiki about your experience with this. Don't worry about where to put it, I will eventually take care to put it under FAQ... TIA Jacques From: "Deyan Tsvetanov" <deyan.tsveta...@ittconsult.com> >I found an issue though: > > If the connection gets dropped during sync : > - the client ( POS ) prints connection reset by peer > - the server ( MCS ) sync status remains to running. > - the next sync does not start because MCS complains there is another > sync running already. > > "Reset run status" from webtools -> entity sync status > helps. > > > I'll investigate further and log a bug, although the solution seems > pretty simple - looks like a swallowed IOException, > which should be handled by re-setting the sync status. > > CHeers, > DEyan > > -----Original Message----- > From: Deyan Tsvetanov <deyan.tsveta...@ittconsult.com> > Reply-to: user@ofbiz.apache.org > To: user@ofbiz.apache.org > Subject: Re: EntitySync RMI error > Date: Sat, 26 Sep 2009 11:22:55 +0300 > > > Got it ! > > Seems that the previous exception was coming from the MCS ( server ) . > When I stopped the server I started getting the exception I kind of like > more :) > > > Message: Exception calling remote pull and report EntitySync service > with name: remotePullAndReportEntitySyncDataRmi; org.ofbiz.service.Gene > ricServiceException: RMI Error (Connection refused to host: > 192.168.1.100; nested exception is: > java.net.ConnectException: Connection refused: connect) > > So the problem was at the server side - RMIIF env var in startofbiz.sh > wasn't set , so ofbiz was trying to get RMI host IP by resolving the > hostname . > > The misleading things for me was that: > 1) no any sign in the MCS logs that somebody is trying to connect and > the MCS itself can not connect to its own RMI registry. > 2) no any difference in the exceptions text on the POS ( client ) side: > the 2 exceptions ( local one - can not connect to 192.168.1.100 and the > remote one - can not connect to 127.0.0.1 ) > look the same :) > > So issue is solved, > sorry for bothering :) > > -- deyan > > -----Original Message----- > From: Deyan Tsvetanov <deyan.tsveta...@ittconsult.com> > Reply-to: user@ofbiz.apache.org > To: user@ofbiz.apache.org > Subject: Re: EntitySync RMI error > Date: Sat, 26 Sep 2009 09:52:55 +0300 > > > During startup I get: > > 2009-09-26 08:46:31,905 (default-invoker-Thread-10) [ > AbstractEngine.java:73 :INFO ] Loaded Service Locations : > [main-rmi=rmi://127.0.0. > 1:1099/RMIDispatcher, > main-http=http://127.0.0.1:8080/webtools/control/httpService, > entity-sync-rmi=rmi://192.168.1.100:1099/RMIDispatcher, > entity-sync-http=http://192.168.1.100:8080/webtools/control/httpService, > rita-rmi=rmi://127.0.0.1:1099/RMIDispatcher, eedcc-test=http://127. > 0.0.1:8080/webtools/control/httpService] > > entity-sync-rmi seems to be ok ... > > > > > -----Original Message----- > From: Deyan Tsvetanov <deyan.tsveta...@ittconsult.com> > Reply-to: user@ofbiz.apache.org > To: user@ofbiz.apache.org > Subject: EntitySync RMI error > Date: Sat, 26 Sep 2009 09:22:23 +0300 > > > Hi guys, > > I'm trying to configure RMI entity sync. I'm following > http://docs.ofbiz.org/display/OFBIZ/Sync+Setup+Notes+and+Example > > What I've done so far: > > 1) entity-sync-rmi to rmi://192.168.1.100:1099/RMIDispatcher > > 2) set RMIIF=-Djava.rmi.server.hostname=127.0.0.1 > ( as per the example ). > > 3) I've imported the entity sync groups, SandJobs, etc. > > However when the sync starts ( on the POS instance ) I get the following > error: > > Exception calling remote pull and report EntitySync service with name: > remotePullAndReportEntitySyncDataRmi; org.ofbiz.service.GenericServic > eException: RMI Invocation Error (Connection refused to host: 127.0.0.1; > nested exception is: > java.net.ConnectException: Connection refused: connect) > Exception: org.ofbiz.service.GenericServiceException > Message: RMI Invocation Error (Connection refused to host: 127.0.0.1; > nested exception is: > java.net.ConnectException: Connection refused: connect) > ---- cause > --------------------------------------------------------------------- > Exception: java.rmi.ConnectException > Message: Connection refused to host: 127.0.0.1; nested exception is: > java.net.ConnectException: Connection refused: connect > ---- cause > --------------------------------------------------------------------- > Exception: java.net.ConnectException > Message: Connection refused: connect > ---- stack trace > --------------------------------------------------------------- > > > It insists connecting to 127.0.0.1 no matter what I type in > serviceengine.xml. > Any help would be appreciated :) > > Thanks in advance, > Deyan >
