Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Guilherme Alan Ritter

+ Follow
since Oct 06, 2014
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Guilherme Alan Ritter

I had to remove this post. Sorry for the inconvenience.
1 month ago

Dave Tolls wrote:

Guilherme Alan Ritter wrote:
There's a big difference between running the query directly and running it in Spring. So you think the VPS is the culprit? Simply upgrading it should do the trick?

Remember, we here are completely detached from what you see.

But if you are getting timings (made up for the sake of example) of something like:

              local machine     VPS
total time     100               1000
time in db    50                 500

then that would imply (to me) that the VPS is simply slower than your local machine.
If those numbers were more like:

              local machine     VPS
total time     100               1000
time in db    50                 850

then that would imply to me that the DB (for whatever reason) was at least pastially responsible.

Note that this is a real "finger in the air" thing, and I would find out exactly what the set up is for your VPS to see whether there is an obvious issue or not before upgrading.
For example, what else shares the VPS hardware.

Seems to me, considering other tests I made, the second example is more likely to be the case.
1 year ago

Dave Tolls wrote:And if you remove those execution times from the earlier times, how much of a discrepancy is left?

If this accounts for almost all of it, then it's the DB that's the issue for some reason.
If there's still a fair chunk of time difference, then you are probably looking at something to do with the VPS or networking (though by the sounds of it the DB and web app sit on the same VPS).

There's a big difference between running the query directly and running it in Spring. So you think the VPS is the culprit? Simply upgrading it should do the trick?
1 year ago

Dave Tolls wrote:OK.
Next step.
Can you access the database directly and run the equivalent find query on it?
You should be able to get it to provide stats for the query, rather than just stop watching it (though that would be handy to show if the VPS is slow).

Check both on your local test machine and on the one on the VPS.

Yes, I can.

Local development machine:

Seq Scan on scale_tests  (cost=0.00..15537.00 rows=19654 width=1014) (actual time=0.073..30.300 rows=19908 loops=1)
 Filter: (where_test > 0.8)
 Rows Removed by Filter: 80092
Planning time: 0.507 ms
Execution time: 30.731 ms


Seq Scan on scale_tests  (cost=0.00..15536.00 rows=19983 width=1014) (actual time=0.016..105.193 rows=19967 loops=1)
 Filter: (where_test > 0.8)
 Rows Removed by Filter: 80033
Planning time: 0.251 ms
Execution time: 106.425 ms

It should be showing that the index is being used, but it's not. I remember it was being used when I tested before...
1 year ago

Dave Tolls wrote:OK, but what is it timing?
Is there enough granularity in the log statements to identify the line (or lines) causing the issue?

Just trying to make sure we aren't looking at the wrong issue here.

I'm timing the time to run entityManager.createQuery("...") (non issue), the time to run repository.find...() (the one that is taking too long, includes the previous timing) and the time to send the request and receive the response (slightly longer than the previous timing).
1 year ago

Dave Tolls wrote:Have you got logging in your system (both client and server)?
Do they show you exactly where the delay is in execution?

Only the logging I made myself, with System.nanoTime() to measure start and stop time and System.out.println() to show it.
1 year ago

Paul Clapham wrote:Is it possible that on your machine, your code and the database were both running on the same machine? Whereas on your VPS, the database is running on a different machine and the query results have to be sent over the network?

I searched a little but I have no idea if that's possible or common.

Oh and I forgot to say: running the query on psql takes about 100 ms without an index and 20 ms with.
1 year ago
Hi everyone.

I've a Spring Boot project which I recently managed to deploy on a VPS. I was very surprised when the select queries that were running nearly instantly on my machine slowed down to a crawl there. I knew it would be slower, I just didn't expect by that much.

I've created a test project that reproduces the issue. It selects about 10 000 rows from a table that contains 100 000 rows. It takes about 100 μs to create the query and 0,5–2 s to run the query. I tried to test with 10× more rows, but it took a lot longer than that and eventually threw OutOfMemoryError.

I searched around and it seems it shouldn't take this long, specially since it seems to me like not a lot of data. I read and learned about indexes but even a query that is supposed to be a good example of index usage takes a lot of time.

If you want to test it, download the server and the client projects and follow the instructions there. I started from my real project and removed as much stuff as possible, but left it similar so it can be compared.


My VPS specs:

2×2,4 GHz CPU


Debian Jessie

Java 8 x64

PostgreSQL 9.4

Spring Boot 2.0.1.RELEASE


Thanks in advance.
1 year ago
I found the solution (sort of). Actually, I didn't just included that property. It's the removal of the org.springframework.validation.Validators that caused the javax.validation validators to stop working. I found out that I needed to have a org.springframework.validation.Validator registered with the before|afterCreate|Save|LinkSave|Delete events and that I had to either call the complex entity's linked entity getter or change it's fetch = FetchType.LAZY to fetch = FetchType.EAGER.

My colleague gave me the suggestion when I mentioned that the NPE happens at a Hibernate code line that reads (see top of stack trace).

Doesn't look like the right way of doing things, but it's working for now. If someone has something to add, I'll be grateful.
2 years ago
Hi everyone.

I'm working on a system's back end that uses Spring Boot, REST, HATEOAS, Hibernate and PostgreSQL. In order to use validation that works both in front end and back end calls without having to call validation methods manually, I'm using ConstraintValidator and @Constraint based validation. To make it work for removals too, which is not default, I had to add in

The problem is that this addition started causing a NullPointerException when I try to delete an entity containing a list of the same type as a member. Simpler entities get deleted just fine. I even removed all validations, but it changes nothing.

Here's a project that's a non operational subset of the project I'm working on, here's the maven dependency tree, and here's the stack trace.

Please help me make it work.

Thanks in advance.
2 years ago
Fixed it. I was a mere reference leak at the end of the 2D inverse transform method.
2 years ago
Hi everyone.

I've developed a program that computes the Wavelet transform of 1D signals and 2D images, complete with a GUI with a few options.

However, there are two bugs which I still haven't been able to figure out, let alone fix.

The first is that the reconstructed image is just wrong, depending on the transform and reconstruction level. Although it's wrong, it resembles the original image.

The second is that the application of a soft threshold is accumulated every time the image view updates, which shouldn't happen.

The weird thing is that these things only happen in the GUI. Running the same code by hand (i.e. in a snippet), it doesn't happen.

The complete code and some more information are available on GitHub, on the following link:

The code is not very optimized, so sorry about that.

If someone can find how to fix these bugs before me, I'll be grateful.

Thanks in advance.

2 years ago
Hi everyone.

I'm completely rewriting this thread because I did some testing and my problem changed completely. I have an (urgent (but don't worry about that)) assignment that requires the usage of threads and semaphores. Because of my design, I also need a chronometer. To help me train semaphore usage, I decided to make the chronometer thread-safe using semaphores too.

When I used a theoretically worse chronometer, the project worked OK most of the time. Now that I'm using a chronometer that is theoretically more correct, and that worked perfectly alone, the chronometer is behaving weirdly when used in the project.

I'll explain the code before posting it. I have the run() method, which runs forever in a while loop. Firstly, it acquires a lock to a semaphore. Then, it reads a boolean variable that determines which path it will take. If it's true, it will do some processing that doesn't block and will release the lock. If the variable is false, it will release the lock and will acquire the lock of another semaphore, which is used in the place of an Object.wait(). This variable is set by other methods only, never inside the run() method.

When I use my chronometer in my project, and I call the startCount() method, it will set the variable to start counting (true) and will release both locks. The run() method, which was blocked in either semaphore, will continue execution and read the variable. But then the variable magically became false again and the chronometer will wait another iteration. If I use successive calls to release the wait semaphore, the variable will still be false.

I even encapsulated the variable to a class, where methods must be used to read/write in it, and every method prints a stack trace. It's executing as expected. The value just magically changes back.

What's going on? I don't think I can post the code for the rest of my project, for it's about 1.600 lines long. I'll post the chronometer and the test harness I used for the individual tests. Remembering that this test harness will not reproduce the error.


Test JFrame:

Thanks in advance.