[JBoss JIRA] (WFCORE-4581) Defining management-interface with https-only socket-bindings causes server to shut down instantly
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFCORE-4581?page=com.atlassian.jira.plugi... ]
Jaikiran Pai commented on WFCORE-4581:
--------------------------------------
This is actually fixed recently by https://issues.jboss.org/browse/WFCORE-4560
> Defining management-interface with https-only socket-bindings causes server to shut down instantly
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4581
> URL: https://issues.jboss.org/browse/WFCORE-4581
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Bartosz Spyrko
> Assignee: Richard Opalka
> Priority: Major
>
> management interface is configured to support only https connections:
> {noformat}
> <management-interfaces>
> <http-interface security-realm="ManagementRealm">
> <http-upgrade enabled="true"/>
> <socket-binding https="management-https"/>
> </http-interface>
> </management-interfaces>
> {noformat}
> On startup the server will not report any errors, but will immediately shutdown:
> {noformat}
> $ ./bin/standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/spyrkob/workspaces/set/tools/installer/wildfly-core/build/target/wildfly-core-9.0.0.Beta4-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:34,016 INFO [org.jboss.modules] (main) JBoss Modules version 1.9.1.Final
> 16:45:34,483 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.5.Final
> 16:45:34,496 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.3.Final
> 16:45:34,660 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 9.0.0.Beta4-SNAPSHOT starting
> 16:45:35,383 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.9.0.CR4
> 16:45:35,536 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 16:45:35,569 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0040: Creating http management service using secure-socket-binding (management-https)
> 16:45:35,592 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.7.1.Final
> 16:45:35,600 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.7.1.Final
> 16:45:35,672 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 5.0.9.Final
> 16:45:35,694 INFO [org.jboss.as.patching] (MSC service thread 1-7) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 16:45:35,715 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-7) WFLYDM0111: Keystore /Users/spyrkob/workspaces/set/tools/installer/wildfly-core/build/target/wildfly-core-9.0.0.Beta4-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 16:45:35,896 WARN [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-7) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> 16:45:35,982 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 16:45:35,988 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Core 9.0.0.Beta4-SNAPSHOT stopped in 2ms
> {noformat}
> In previous release this was a valid settings, the problem seems to have been introduced by WFCORE-4442
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2364?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2364:
---------------------------
Fix Version/s: 4.1.2
> simply lock and unlock JGroups lock repeatedly will create chaos
> ----------------------------------------------------------------
>
> Key: JGRP-2364
> URL: https://issues.jboss.org/browse/JGRP-2364
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Environment: JDK: 1.8
> JGroups: 4.1.1
> Lock: CENTRAL_LOCK
> Reporter: Yong Deng
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
> Attachments: LockSimpleTest.java
>
>
> I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?*
> * Current log:
> {code:java}
> 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000]
> 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A]
> 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> {code}
> * The expected log:
> {code:java}
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2362) Providing logical member name in JDBC_PING
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2362?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2362:
---------------------------
Fix Version/s: 4.1.2
> Providing logical member name in JDBC_PING
> ------------------------------------------
>
> Key: JGRP-2362
> URL: https://issues.jboss.org/browse/JGRP-2362
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.17, 4.0.18, 4.0.19, 4.1.0, 4.0.20
> Reporter: S Pokutniy
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
>
> When using JDBC_PING and logical names instead of UUIDs and one of the cluster member crashes or get killed and this member is not coordinator then its database set still remains in the database as long as coordinator changes (independently from remove_old_coords_on_view_change /remove_all_data_on_view_change). If the the cluster is then restarted the old dataset makes connect() much slower (+30 seconds), as the members seem to be tryting to connect to it. Parameter remove_all_data_on_view_change seems to be the solution but it does not work as long as coordinator does not change, so practically the same as remove_old_coords_on_view_change.
> The only solution seems to be to provide an appropriate delete statement in parameter initialize_sql, which would delete old entry, for example like this: delete from JGROUPSPING where ping_data like '%logical name%'. However, this is neither really quick nor the ideal solution, as ping_data's datatype is bytea or bit varying.
> It would be great to have also logical name in JGROUPSPING, which is instead per default in insert(). This is also easy to implement as there is access to this information in PingData.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2360) DeadLock while acqiring a distributed lock consecutively by the same thread in a loop
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2360?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2360:
---------------------------
Fix Version/s: 4.1.2
> DeadLock while acqiring a distributed lock consecutively by the same thread in a loop
> -------------------------------------------------------------------------------------
>
> Key: JGRP-2360
> URL: https://issues.jboss.org/browse/JGRP-2360
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.18, 4.1.1
> Environment: JGroups-4.1.1-Final
> Red Hat 4.4.7-23
> JDK 1.8.0_202
> Reporter: Daniel Klosinski
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
> Attachments: DLTest.java, DistributedLockRepoducer.zip, log.log
>
>
> Deadlock intermittently happens when trying to acquire a distributed lock by the same VM, consecutively by the same thread in a loop. Here is a code snippet for which this issue can occur :
> {code}
> for(String s : list){
> Lock lock=lock_service.getLock("test_lock_name");
> lock.lock();
> //perform bussines logic
> lock.unlock();
> }
> {code}
> Running such loop I am getting dead look after a few loop iterations. In the attached logs program hanged after 3 iterations
> During the troubleshooting, I found out that lock_id is not being incremented for the new distributed lock. In the first two loop iterations everything was fine. At the third iteration lock_id didn't get increased:
> {code}
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=1, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: RELEASE_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: RELEASE_LOCK_OK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 --> svc-1-sps-4688: GRANT_LOCK[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: CREATE_LOCK[test_lock_name, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> 2019-07-15 16:03:32 TRACE CENTRAL_LOCK:163 - svc-2-sps-34594 <-- svc-1-sps-4688: LOCK_GRANTED[test_lock_name, lock_id=2, owner=svc-2-sps-34594::1, sender=svc-1-sps-4688]
> {code}
> I've added few extra loggers into Jgroups-4.1.1.Final code and I realized that the second client lock was not removed from the client lock table before the creation of 3rd client lock. The issue lays in below piece of code. Owner consists of address and threadID. If the same thread, on the same VM, creates distributed lock consecutively and if there is an existing entry in the client lock table for the same owner, the new lock won't be created. The old client lock will be used to acquire a new distributed lock :
> {code}
> protected synchronized ClientLock getLock(String name, Owner owner, boolean create_if_absent) {
> Map<Owner,ClientLock> owners=table.get(name);
> if(owners == null) {
> if(!create_if_absent)
> return null;
> owners=Util.createConcurrentMap(20);
> Map<Owner,ClientLock> existing=table.putIfAbsent(name,owners);
> if(existing != null)
> owners=existing;
> }
> ClientLock lock=owners.get(owner);
> if(lock == null) {
> if(!create_if_absent)
> return null;
> lock=createLock(name, owner);
> owners.put(owner, lock);
> }
> return lock;
> }
> {code}
> I believe that this issue was introduced by the fix for JGRP-2234 and it is caused by the race condition. The logic that deletes client lock from the client lock table is now executed when the client's VM receives RELEASE_LOCK_OK message from the coordinator. Previously this deletion was executed by the thread in which unlock() method was called. Now, it is executed by the separate thread which handles RELEASE_LOCK_OK from the coordinator and this is why we have a race condition here. Here is a sequence which leads to deadlock:
> 1. Create client lock (lock_id=2)
> 2. Send GRANT_LOCK (lock_id=2) to coordinator
> 3. Receive LOCK_GRANTED (lock_id=2) from coordinator
> 4. Send RELEASE_LOCK (lock_id=2) to coordinator
> 5. Call look() method in the same thread (new client lock won't be created as there is an existing entry in the client lock table for this owner)
> 6. Receive RELEASE_LOCK_OK and delete client lock from client lock table.
> 7. Send GRANT_LOCK (lock_id=2) to coordinator
> 8. Receive LOCK_GRANTED (lock_id=2) from coordinator
> 9. No entry in the client lock table. It's not possible to get the thread which needs to be notified.
> I am attaching a simple program which can be used to reproduce and generated logs.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2359) Route list can be empty
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2359?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2359:
---------------------------
Fix Version/s: 4.1.2
> Route list can be empty
> -----------------------
>
> Key: JGRP-2359
> URL: https://issues.jboss.org/browse/JGRP-2359
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1, 4.0.20
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 4.1.2
>
>
> The list of routes is changed without proper synchronization. One example, I got an empty list when in Infinispan when try to select the route to use:
> {code}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
> at java.util.ArrayList.get(ArrayList.java:433)
> at org.infinispan.remoting.transport.jgroups.SiteMasterPickerImpl.pickRoute(SiteMasterPickerImpl.java:26)
> at org.jgroups.protocols.relay.Relayer.getRoute(Relayer.java:126)
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:566)
> at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:425)
> at org.jgroups.stack.Protocol.down(Protocol.java:317)
> at org.jgroups.fork.ForkProtocol.down(ForkProtocol.java:42)
> at org.jgroups.fork.ForkProtocolStack.down(ForkProtocolStack.java:62)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:222)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:21)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.send(JGroupsTransport.java:1035)
> {code}
> One possible solution is to do a copy of the list before changing it in the view change method invocation (for the bridge)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Michael Musgrove commented on WFLY-12317:
-----------------------------------------
The problem is that many of our properties are statically initialised and are read once at boot time. The "node-identifier" is one such property and it is statically initialised (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...).
We cannot just make every property dynamic since some properties are dependent on each other and setting one can introduce race conditions (with for example periodic recovery) so we could only do that through careful analysis and I doubt the benefits are worth while.
The node-identifier model attribute (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...) should be set to RESTART_JVM not reload.
The failing test is testing that another server is able to recover logs from another server. We do support this type of "proxy recovery" but the relevant attribute is not exposed in the management model (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...),
My recommendation is to:
- change the test to perform a JVM restart instead of a reload.
- update the WildFly management model attribute to require a JVM restart when it is set
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Michael Musgrove
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12329) ManagedScheduledExecutorService should be only available after server is ready
by nimo stephan (Jira)
[ https://issues.jboss.org/browse/WFLY-12329?page=com.atlassian.jira.plugin... ]
nimo stephan updated WFLY-12329:
--------------------------------
Description:
I use a *ManagedScheduledExecutorService* to execute tasks periodically:
{code:java}
@Startup
@Singleton
public class TaskScheduler {
@Resource
ManagedScheduledExecutorService executorService;
@PostConstruct
public void init() {
executorService.scheduleAtFixedRate(this::task, 0, 5, TimeUnit.SECONDS);
}
public void task() {
System.out.println("long running task:" + LocalTime.now());
}
}
{code}
Wildfly throws a few exceptions as long as server is not fully initiated and in "suspend"-mode:
{code:java}
12:44:12,715 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.IllegalStateException: WFLYEE0111: Cannot run scheduled task my.Task$$Lambda$1041/0x000000080240a040@5ee966ec as container is suspended
at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:164)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383)
at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:835)
at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
{code}
I use _ManagedScheduledExecutorService_ instead of _ScheduledExecutorService_ in JEE because, *ManagedScheduledExecutorService* should be managed by JEE. Hence, the server should also manage and guarantee not to fire the executorService until the server is ready (and EJBs are available).
was:
I use a *ManagedScheduledExecutorService* to execute tasks periodically:
{code:java}
@Startup
@Singleton
public class TaskScheduler {
@Resource
ManagedScheduledExecutorService executorService;
@PostConstruct
public void init() {
executorService.scheduleAtFixedRate(this::task, 0, 5, TimeUnit.SECONDS);
}
public void task() {
System.out.println("long running task:" + LocalTime.now());
}
}
{code}
Wildfly throws a few exceptions as long as server is not fully initiated and in "suspend"-mode:
{{
{code:java}
12:44:12,715 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.IllegalStateException: WFLYEE0111: Cannot run scheduled task my.Task$$Lambda$1041/0x000000080240a040@5ee966ec as container is suspended
at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:164)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383)
at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:835)
at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
{code}
}}
I use "ManagedScheduledExecutorService" instead of "ScheduledExecutorService" in JEE because, *ManagedScheduledExecutorService* should be managed by jee. Hence, the server should also manage and guarantee not to fire the executorService until the server is ready (and EJBs are available).
> ManagedScheduledExecutorService should be only available after server is ready
> ------------------------------------------------------------------------------
>
> Key: WFLY-12329
> URL: https://issues.jboss.org/browse/WFLY-12329
> Project: WildFly
> Issue Type: Bug
> Components: Concurrency Utilities
> Affects Versions: 17.0.1.Final
> Reporter: nimo stephan
> Assignee: Eduardo Martins
> Priority: Major
>
> I use a *ManagedScheduledExecutorService* to execute tasks periodically:
> {code:java}
> @Startup
> @Singleton
> public class TaskScheduler {
> @Resource
> ManagedScheduledExecutorService executorService;
> @PostConstruct
> public void init() {
> executorService.scheduleAtFixedRate(this::task, 0, 5, TimeUnit.SECONDS);
> }
> public void task() {
> System.out.println("long running task:" + LocalTime.now());
> }
> }
> {code}
> Wildfly throws a few exceptions as long as server is not fully initiated and in "suspend"-mode:
> {code:java}
> 12:44:12,715 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.IllegalStateException: WFLYEE0111: Cannot run scheduled task my.Task$$Lambda$1041/0x000000080240a040@5ee966ec as container is suspended
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:164)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383)
> at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:835)
> at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> {code}
> I use _ManagedScheduledExecutorService_ instead of _ScheduledExecutorService_ in JEE because, *ManagedScheduledExecutorService* should be managed by JEE. Hence, the server should also manage and guarantee not to fire the executorService until the server is ready (and EJBs are available).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months