orientdb 1.6.3. I haven't tried with 1.7-rc2 The plocal write succeeds but is not visible to the other JVM through plocal or remote. Then successive writes through remote result in the cluster inconsistent message in the console (even though the remote write succeeds and is visible everywhere). I can see that the rids get out of sync so corruption will not be isolated to one record.
On Thursday, February 27, 2014 5:42:02 AM UTC-5, Lvc@ wrote: > > Hi, > we've clients in production with such mode and as you wrote has so many > advantages in comparison with classic client/server mode. > > So what's the replication error? Are you using 1.7-rc2? > > Lvc@ > > > > On 27 February 2014 11:38, odbuser <[email protected] <javascript:>>wrote: > >> Bump... In summary, I want to know if the use of plocal is "cluster" >> safe in this scenario. If it is *supposed* to be cluster safe, then there >> is a bug that I can report. If it is known to be cluster unsafe, is there >> an enhancement that would make plocal cluster safe? >> >> JVM1 : 3 ports open (binary listener for remote access, hazelcast for >> clustering, http port for web app) clustered with JVM2, plocal used >> internally by a web app. >> JVM2 : 3 ports open (binary listener for remote access, hazelcast for >> clustering, http port for web app) clustered with JVM1, plocal used >> internally by a web app. >> >> Note, I normally would not have the binary listener turned on for remote >> access b/c it can't currently be secured. I have them on so that I can >> verify cluster consistency through an attached console. >> >> *The good part:* >> read/writes are consistent through consoles attached to remote of each >> JVM. >> read is consistent through the web app which uses plocal. >> >> *The bad part:* >> write succeeds through web app which uses plocal but then the reads are >> inconsistent using the remotes as well as through the other JVM's web app. >> >> The benefit of having this topology is as follows: >> >> - Each VM doubles as a redundant node for the database and the web >> app. This reduces complexity. >> - Fastest topology. Each web app uses the fastest database access >> method (plocal) and each client can (under most circumstances) stick to >> the >> first node that they were load balanced to. If the orientdb remote >> connection balancing were used, the chance for inconsistencies increases >> substantially. >> - Reduces security requirements. The http port and hazelcast port >> can run securely but orientdb remote: connections currently can't. >> Eliminates unsecure connections from web app to database - but doesn't >> preclude it if the remote connection apis are secured in the future. >> >> If this does not work and the remote method is mandatory, then I need to >> investigate patching orientdb to support secure sockets. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
