[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 10:17 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* -CreditMap- (only used to compute elapsed time for stats)
* FlowControl
* Locking
* -MERGE2-
* RELAY2
* -StatsCollector-
* RATE_LIMITER
* -PERF-
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* -CreditMap- (only used to compute elapsed time for stats)
* FlowControl
* Locking
* MERGE2
* RELAY2
* -StatsCollector-
* RATE_LIMITER
* -PERF-
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 10:10 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* -CreditMap- (only used to compute elapsed time for stats)
* FlowControl
* Locking
* MERGE2
* RELAY2
* -StatsCollector-
* RATE_LIMITER
* -PERF-
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* -StatsCollector-
* RATE_LIMITER
* -PERF-
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 10:07 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* -StatsCollector-
* RATE_LIMITER
* -PERF-
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* -PERF-
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 10:06 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* -PERF-
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 10:05 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere)
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* ConcurrentLinkedBlockingQueue
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 10:03 AM:
----------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* -HashedTimingWheel- (not changed; as unsupported)
* ConcurrentLinkedBlockingQueue
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* HashedTimingWheel
* ConcurrentLinkedBlockingQueue
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/12/14 9:50 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* -TimeScheduler2- (not changed; deprecated)
* HashedTimingWheel
* ConcurrentLinkedBlockingQueue
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* -TimeScheduler3-
* TimeScheduler2
* HashedTimingWheel
* ConcurrentLinkedBlockingQueue
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
Jesper Pedersen closed JBJCA-1181.
----------------------------------
Resolution: Done
Use a security domain
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.2.0.Beta4, 1.0.27.Final
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
Ivo Studensky reopened JBJCA-1181:
----------------------------------
It still does not work as stated in the referenced BZ, thus I am proposing a new fix which will allow empty password in a datasource, see
https://github.com/istudens/ironjacamar/compare/ironjacamar:1.0...JBJCA-1...
The EAP part can be seen here:
https://github.com/istudens/jboss-eap/compare/jbossas:6.3.x...bz1130281?e...
Jesper, could you review it please? Thanks.
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-875) Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
by Daniel Zwicker (JIRA)
[ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.s... ]
Daniel Zwicker commented on WFLY-875:
-------------------------------------
I have just hit this problem with wildfly 8.1.0. The workaround from John works.
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-875
> URL: https://issues.jboss.org/browse/WFLY-875
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: JBoss 7.1.1
> Reporter: Sławomir Wojtasiak
> Assignee: Stuart Douglas
> Labels: rhq
> Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
> @Override
> public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
> configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
> configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
> if(description.isPassivationApplicable()) {
> configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> }
> configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
> }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer’s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel}
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years