Re: [h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread SkiAddict
On Tuesday, 20 December 2016 19:08:09 UTC+13, Noel Grandin wrote: > > Also, this might be useful > > http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/ > ​ > Gr! Nothing I do gets rid of the damn old hostname!!! Did the above twice, restarted, did it again, restarted, and still all I

Re: [h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread Noel Grandin
On 20 December 2016 at 03:13, SkiAddict wrote: > > I'm wondering if perhaps there is a gremlin in that string, since in > stepping through the library code starting at > InetAddress.getLocalHost().getHostName(), > the *only* place it lags is a call to StringCoding.encode() from > String.getBytes

Re: [h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread Noel Grandin
Also, this might be useful http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/ ​ -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscr...@goo

[h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread SkiAddict
Curiouser and curioser... Both the local host and the computer name are now "trial", and the hard disk name is now "tt", so there are no remnants of "Santa's MacBook" anywhere AFAICS. I've run OnyX to clean the system caches (boot, kernel and extensions, CUPS jobs (not related to this issue, b

[h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread SkiAddict
Actually, I spoke too soon. I decided to run Wireshark again and see what it said. Launching the h2 console now only takes 58s as opposed to the 1m25s of previously. Still too slow, but an improvement. (The reason I originally said there was no improvement is that unless I'm doing something

Re: [h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread SkiAddict
On Tuesday, 20 December 2016 11:35:49 UTC+13, Tomas Pospichal wrote: > > I have seen slow local network connections from Java on other platforms, > but with H2 it seems to be OSX or mac OS users who are running into it. > Similar problems have been discussed here last month: H2 database running

Re: [h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread Tomas Pospichal
I have seen slow local network connections from Java on other platforms, but with H2 it seems to be OSX or mac OS users who are running into it. Similar problems have been discussed here last month: H2 database running really slow on mac OS sierra https://groups.google.com/d/msg/h2-database/H-

Re: [h2] Re: Please help, h2 console in El Capitan very very slow!!!

2016-12-19 Thread SkiAddict
On Monday, 19 December 2016 19:04:39 UTC+13, Noel Grandin wrote: > > ok, so it's hanging in the > at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) > at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928) > at java.net.InetAddress.getAddressesFromNameService(Ine

Re: [h2] MVStore with MVCC performance degradation

2016-12-19 Thread Mayank Tankhiwale
Hi Thomas, We am getting the "Missing lob entry ... " exception quite frequently on concurrent update and read of a row. My connection URL is as follows: "jdbc:h2:/data/database;MVCC=true;CACHE_SIZE=2621440;PAGE_SIZE=4096;ALLOW_LITERALS=NUMBERS;LOCK_TIMEOUT=1;" We were on 1.3.176, but updati

Re: [h2] Missing lob entry on concurrent update read of a row

2016-12-19 Thread Noel Grandin
On 2016/12/19 3:20 PM, Mayank Tankhiwale wrote: I am getting exceptions stating "Missing lob entry" on concurrent update and read of a row in the table. i.e. one thread/connection is reading(in loop) meanwhile another thread comes and updates the CLOB. After that when the previous thread rea

[h2] Missing lob entry on concurrent update read of a row

2016-12-19 Thread Mayank Tankhiwale
Hi, I am getting exceptions stating "Missing lob entry" on concurrent update and read of a row in the table. i.e. one thread/connection is reading(in loop) meanwhile another thread comes and updates the CLOB. After that when the previous thread reads the row, it is failing with high probability