> BTW: I currenty own the required grants since oracle is running on my own
laptop. But I know that this will cause trouble when installing Artemis in
our production environment.

Probably it could be a latency issue too: there are several configuration
properties
<https://activemq.apache.org/artemis/docs/latest/persistence.html> that
could be tuned to allow working with high latency connection (but it is not
reccomended TBH):

   - *jdbc-lock-acquisition-timeout* The max allowed time in milliseconds
   while trying to acquire a JDBC lock. The default value is 60000
   milliseconds (ie 60 seconds).
   - *jdbc-lock-renew-period* The period in milliseconds of the keep alive
   service of a JDBC lock. The default value is 2000 milliseconds (ie 2
   seconds).
   - *jdbc-lock-expiration* The time in milliseconds a JDBC lock is
   considered valid without keeping it alive. The default value is 20000
   milliseconds (ie 20 seconds).

*jdbc-lock-acquisition-timeout *could be turned to -1 ie infinite and the
others could be raised to appropiate values considering the DBMS latencies
(eg I would say renew to 10 seconds and expiration to 60 seconds).

> 3) no I haven't tried the latest master. But since I do not find a related
issue in JIRA I assume that it still exist.

Some time ago I've opened (and it is already merged on master) Make the
JDBC Node Manager more resilient on failures
<https://issues.apache.org/jira/browse/ARTEMIS-1541> to address cases like
this, hopefully it will solve it.

> And I can see that the broker is holding a lock on that table. So it
tries to
insert something which fails but does not properly rollback...

That's strange but not impossible: there is a rare case of a leaking and
unkilleable Oracle driver thread called:
oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser
<https://support.oracle.com/knowledge/Middleware/2241504_1.html>.
It could be the one actually locking that table.

Cheers,
Franz



Il giorno ven 26 gen 2018 alle ore 14:44 Archibald <arch...@gmx.net> ha
scritto:

> And I can see that the broker is holding a lock on that table. So it tries
> to
> insert something which fails but does not properly rollback...
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Reply via email to