Activity for Johan Compagner
-
Johan Compagner posted a comment on ticket #556
yeah i fixed it by just setting the NSISCONFDIR environment variable to the dir (where also the executable is in..) Problem is that it is not installed in the system, but i just extract a tar file in a mvn target dir and then run it directly from there
-
thx it took a while to figure it out and try a few runs (you cant mix/match stuff with command line arguments and what is in the config file) so i don't give any arguments related to compression and have those all in the nsisconf.nsh file: OutFileMode aio SetCompressor /FINAL /SOLID lzma then it works and it is much faster compressing it and also decrompressing it. Problem is this works on windows: [INFO] [MAKENSIS] Processing config: xxxxxx\target\nsis\nsisconf.nsh [INFO] [MAKENSIS] OutFileMode:...
-
aio is default right? (so auto is aio?) because i get this: SetCompressor: ignoring /SOLID flag due to OutFileMode auto (:6) problem is a bit i can't really easily set that because i use mvn and this plugin: https://github.com/DigitalMediaServer/nsis-maven-plugin so can't easily just set random stuff i think :(
-
i would love to use solid compression and then i don't really care if the compression speed is not so high.. If that would help the download size and maybe also the install speed, that would be great The only problem is that there is no option to support solid compression and still have 1 (exe) file so that is kind of a bummer..
-
Thx Jason, first question: can you now merge your stuff really into the main product? (before we are getting all kinds of forks). So have maybe a discussion with the team? Second thing is, i moved to your fork for our product and it is way faster compressing and making the installer.. instead of that it took +/-370 seconds, it now takes +/-115 seconds. so that is a nice improvement but for me not the most important one, that is extracting, but the size did increase it went up from 569MB (56.6%) to...
-
Thx Jason, first question: can you now merge your stuff really into the main product? (before we are getting all kinds of forks). So have maybe a discussion with the team? Second thing is, i moved to your fork for our product and it is way faster compressing and making the installer.. instead of that it took +/-370 seconds, it now takes +/-115 seconds. so that is a nice improvement but for me not the most important one, that is extracting, but the size did increase it went up from 569MB (56.6%) to...
-
Thx Jason, first question: can you now merge your stuff really into the main product? (before we are getting all kinds of forks) Second thing is, i moved to your fork for you product and it is way faster compressing and making the installer.. instead of that it took +/-370 seconds, it now takes +/-115 seconds. so that is a nice improvement but for me not the most important one, that is extracting, but the size did increase it went up from 569MB (56.6%) to 585MB (58.2%). But because of the big improvement...
-
problem is a bit that is now more then 10 years ago.. Also he talks a lot about "compression" not decompession I can live with some compression time (which i do making an installer) But the decompression time i find way more important, because that is what our customers (using the installer) are facing, slow install times.. and that can be some much faster...
-
i personally don't really care about compressing (for a product that is done by the build pipe line, is nice that thats faster, but not directly really important to me) But installing is just very slow, i don't get why this is not picked up over all these years.. For now i also have a "zip" installer for our product, and if i test my self i will always take the zip. because that extracts/installs so much faster....
-
i rather do the latter, try not to use clobs at all. Problem is there are scenario's that we don't know up front the size (so calling varchar(1000) is not something we know. i am looking into this: http://hsqldb.org/doc/2.0/guide/sqlgeneral-chapt.html#sgc_char_types now i do wonder what the difference between them all are varchar longvarchar clob i guess varchar needs a size right? so if we create varchar(16M) thats the same as just using longvarchar without a size? and clob(16M) is really different...
-
i guess i dont really need to set it right? If reading the doc it says "the default maximum is 50MB"
-
we finally figured it out what it was, it was not really the drop table statement (that did go through) but what we also did to clean it up was sending a "CHECKPOINT" because of https://sourceforge.net/p/hsqldb/bugs/1578/ and that checkpoint is problematic because that needs a full lock on the database. so if there is at least 1 (long) transaction running , that wil block the CHECKPOINT from being executed. But if we did send it there is another problem then all other transactions that want to start...
-
So if there is just 1 dedicated connection that does all the dropping, then there will never be a session (with a connection from a pool) that will block on others because drop is the one that wants to have an exclusive lock on the whole database? And it can then happen that the dedicated "hangs" for a while if others are locking, having transactions, but that doesn't really matter because in the end it will go on, and sessions won't be affected?
-
this is still a bit of a problem for us and i wonder if you have an idea how to fix this then completely First what we do: we use a hsqldb connection pool to an in memory database where sessions (like an websocket or http session in tomcat) can create quickly tables and store data for their session. Sessions never see other sessions data, we make sure that we generated tables based on uuid's (the names). We can't use " DECLARE LOCAL TEMPORARY TABLE" because i think that is based on the connection,...
-
right and we need to be able to create tables in the middle of transactions and those creates should not block So this is not possible for MVCC mode so we can't use it. And with default mode this is possible we don't really see blocks there but for that we really have current in none reproducible sample where drops are just all blocking and never return Does a drop table in default lock mode also wants to have a full lock? (and create is relaxed?)
-
oh wait my last statement is wrong the same hanging stack we get in 2 different modes in mvcc mode we get 1 thread hanging like that when doing a create statement but in normal/default mode we get the same hanging stack but then for drop tables but then many threads doing that (and they never get out of it)
-
the confusion here is a bit about the focus on "single thread" that is not the problem here this also hangs: Thread thread = new Thread(() -> { try { Statement statement2 = connection2.createStatement(); statement2.execute("create table table2 (id integer, data varchar(50), primary key (id))"); statement2.close(); } catch (SQLException e) { e.printStackTrace(); } }); thread.start(); thread.join(); and thats kind of our situation if we would do it in multiply threads. Because the 1 with the transaction...
-
i can have 2 transactions on different threads also making a deadlock thats not the point. It shouldn't matter in what thread you are, i really don't understand that A connection should juts be a connection not tied to a thread. There are all kind of thread pools in this world and different usage how those are used over many threads in pools.. If i create a deadlock because of transactions hitting the same table, then that is my problem, but doing a create or drop table in any connection even if...
-
this is in a real system with thread pools and connection pools really tricky to always get right So it really would be better if there where no deadlocks like this. Many times we don't control threads, they are just calls from a Servlet container (rest or rcp) and the server only has a connection pool and a session pool with transactions (connections) Why would you need to wait for stuff? if you just create or drop a table that has nothing todo with the select statement for a completely different...
-
yes we have the same problem, i don't fully understand that this is not way more higher prio i dont care to much about compressing (our build server makes installers and that doesn't happen all the time) But our customers installing it is very slow. If i have exactly the same data in a 7zip archive and i uncompress it with 7zip it is so much faster..
-
yes we have the same problem, i don't fully understand that this is not way more higher prio i dont care to much about compressing (our build server makes installers and that doesn't happen all the time) But our customers installing it is very slow. If i have exactly the same data in a 7zip archive and i compress it with 7zip it is so much faster..
-
we use mem: for the most part, all of those are temp tables (but temp in our sense, i think for hsql its just plain tables, that we create or drop for a specific (http)session) so HSQL is used as some kind of cache for us, we don't really need or want file: persistence problem now is if one of thoe tables are using "clob" it will go out of mem in a certain point of time. So for us doing "CHECKPOINT" is not about file size, log files or sync to the disk in anyway its plainly for us to release mem...
-
lowering the block size is not really a solution, because then in the end you will have the same problem... But yes executing a "CHECKPOINT" will result in the lobs being cleared (at least what i see on disk) But why would i do that manually? So the default behavior that we use where we create tables (could be temp) where we insert lobs and delete then rows again, maybe even delete the whole table (if temp tables) the memory will grow and grow? Why is hsqldb not doing what CHECKPOINT does now and...
-
using clob as a column type will result in a out of mem (or ever growing file)
-
decompression is much slower then if you would 7zip (same content)
-
is this also the reason why it is so much slower to decompres? if i have the generated installer a zip of that same content or a 7zip of that same content and i use 7zip for extracting the zip or the 7zip file: 33s 7zip (as 7zip) 35s 7zip (as zip) 1m42s installer thats a huge difference...
-
skip this, found the problem
-
<skip this,="" found="" the="" problem="">
-
Hi i have a directory with 2 folders, 1 of those folders is named META-INF and has...
1