With 1.7-rc1 and after this runs fine. We introduced adaptive timeouts and other cool stuff in 1.7-rc2-SNAPSHOT, so I suggest you to use this.
Lvc@ On 27 February 2014 11:59, odbuser <[email protected]> wrote: > 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]> 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]. >>> >>> 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. > -- --- 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.
