I'm going to try to minimise use of this (as per
https://github.com/google/guice/wiki/Avoid-Injecting-Closable-Resources).
For example, I'm going to inject a pooling DataSource rather than
Connection objects, as per the advice at the end of the page. However,
HikariCP's DataSource implementation is itself Closeable.
Signed-off-by: Graham <gpe@openrs2.org>
The previous code included too many rows as the use of LEFT JOINs meant
candidate group orws with an incorrect container_id were still included
in the results.
Using an IN clause with a subquery allows us to remove those rows,
though it's a bit hacky.
(Really I want to be able to use the JOIN on the right side of a LEFT
JOIN to restrict the rows that appear in the results of the LEFT JOIN,
but that doesn't seem to be possible.)
This is similar to the issue fixed by
a920570f04.
Signed-off-by: Graham <gpe@openrs2.org>
Some non-empty loc groups are also unreachable, so I think this was
quite deceptive - e.g. on some OSRS revisions, we'll probably never hit
100% of the keys even if we exclude empty loc groups.
We can include the empty loc flag in the list of missing keys on the
per-cache pages instead.
Signed-off-by: Graham <gpe@openrs2.org>
The previous code over-counted as the use of LEFT JOINs meant candidate
group rows with the incorrect container_id were still included in the
results. Using an IN clause with a subquery allows us to remove those
rows, though it's a bit hacky. (Really I want to be able to use a JOIN
on the right side of a LEFT JOIN to restrict the rows that appear in the
results of the LEFT JOIN, but that doesn't seem to be possible.)
Signed-off-by: Graham <gpe@openrs2.org>
While the client doesn't appear to be capable of producing a trailing
block with a non-zero next block pointer (though I may have misread the
code), there are caches out there in the wild with trailing non-zero
next block pointers.
When it is reading a group, the client ignores these.
Therefore, for compatibility with the client and existing caches, this
commit removes the StoreCorruptException thrown in this case.
Signed-off-by: Graham <gpe@openrs2.org>
This commit also adds support for populating the whirlpool column, and
ensures version is set to 0 for the ORIGINAL master index format.
Signed-off-by: Graham <gpe@openrs2.org>
Green indicates we've collected a full set. For indexes, red indicates
some are missing (as this is a critical problem - the client won't start
at all if an index is missing). Yellow indicates groups or keys are
missing, as this is less critical (the client will likely work in most
cases).
Signed-off-by: Graham <gpe@openrs2.org>
I'm not sure if the auto-detection code works: I'm assuming that the new
format was introduced at the same time as the lengths flag in Js5Index,
but I haven't confirmed this.
Signed-off-by: Graham <gpe@openrs2.org>
This commit makes the following changes:
- Uses XteaKeyDeserializer instead of reading the key array manually.
- Adds support for an object of map squares to keys, which is the format
used by the OpenOSRS XTEA endpoint.
- Throws exceptions if the input is malformed, rather than silently
ignoring problems.
Signed-off-by: Graham <gpe@openrs2.org>
This was actually only compatible with OpenOSRS's code (RuneLite uses a
completely different API). Furthermore, I don't think it's really going
to be necessary as we've arranged access to RuneLite's XTEA API.
Signed-off-by: Graham <gpe@openrs2.org>
