Updating database leads to mis-categorisation of user agents about udger-java

[skybber]

Did you really updated DB when the clients were running ? If so, then it is not suprising that the client crashed. You should always stop the parser before you update the DB .

[kutchar]

@skybber What is the correct procedure to update the DB when using the inMemoryEnabled=true?
A bit context, I have a cron that updates the DB nightly and I have a long running Java process that loads the DB into memory and processes the requests. We would like to reload the DB when the DB file is updated without restarting the Java process.

[gierlachg]

We have similar use case - reloading DB without process restart.
I believe it might be related to UdgerParser static members...

private static WordDetector clientWordDetector;
private static WordDetector deviceWordDetector;
private static WordDetector osWordDetector;

private static List<IdRegString> clientRegstringList;
private static List<IdRegString> osRegstringList;
private static List<IdRegString> deviceRegstringList;

Is there any specific reason for them to be static? Using parser from multiple threads is not safe anyway as far as I know.

[skybber]

The original idea was to keep expensive precalculated data in static cache, but it seems that most frequent use case is not to create Parsers frequently. I have to check how is it with memory consumption. Anyway the thread safety is ridden by mysql driver, which is not thread safe.

[gierlachg]

Have you managed to verify memory consumption? Is it feasible to get rid of statics and make Udger reloadable?

[skybber]

Parser stores precalculated data in statics. We can store them in a some non-static context, but then we have to change the parser API. For now, I've added static reset method to nullify them, but we have to extend the API by the context in the future. Would be the reset method enough for you?

[gierlachg]

I don't think 'reset' would be appropriate for us.
Right now we have a pool of parsers, accessed from many threads (however one at a time).
We would like to be able to create new instance of parser (with latest data) while old one could still be theoretically in use (ongoing requests etc.).

[skybber]

Are you using same file dbFileName for old/new DB ?

[gierlachg]

I'm not sure I understand what you mean.
While creating UdgerParser we pass dbFileName, yes. For different versions it is a different file though.

[skybber]

Runtime DB change support just added in v1.1.0.

[gierlachg]

Awesome. Thanks!