[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5857:
------------------------------------
Please see the documentation for this feature here: https://docs.jboss.org/author/display/WFLY10/HA+Singleton+Features
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5857
> URL: https://issues.jboss.org/browse/WFLY-5857
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha
> Reporter: Serg Jakean19019
> Assignee: Paul Ferraro
>
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again.
> If Node2 ist started again, than Start is called in Node1 again.
> This Solution worked in 8.2.0.Final and was taken from GitHub
> Part of Log after Stop in Singletone:
> 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service.
> 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service
> 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c
> 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1]
> 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms)
> 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms)
> This issue also in:
> https://developer.jboss.org/thread/266831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6298) Test suite crashes at : "jipijapa Hibernate 4.3.x (JPA 2.1) integration"
by Shishir Subramanyam (JIRA)
Shishir Subramanyam created WFLY-6298:
-----------------------------------------
Summary: Test suite crashes at : "jipijapa Hibernate 4.3.x (JPA 2.1) integration"
Key: WFLY-6298
URL: https://issues.jboss.org/browse/WFLY-6298
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 10.0.0.Final
Reporter: Shishir Subramanyam
Priority: Trivial
Attachments: Wildfly test suite error.JPG
The test suite fails at the step : "jipijapa Hibernate 4.3.x (JPA 2.1) integration". I did not make any changes to the code before running "mvn install" through cmd(windows) in the base directory
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-232) Unclean shutdown of deployment scanner
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-232?page=com.atlassian.jira.plugin... ]
Ondrej Zizka commented on WFCORE-232:
-------------------------------------
I'm working with EAP 7 Beta. Un/Deploying using wildfly maven plugin. EAP sometimes gets to a state when writes this exception repeatedly and can't deploy and run the app.
> Unclean shutdown of deployment scanner
> --------------------------------------
>
> Key: WFCORE-232
> URL: https://issues.jboss.org/browse/WFCORE-232
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Beta4
>
>
> I happened to see this in a testsuite log file:
> {code}
> 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530)
> at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619)
> at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669)
> at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.)
> Waiting for tasks to complete could be tricky, e.g. imagine this race:
> 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services.
> 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock.
> Deadlock.
> Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit.
> But ^^^ is just a quick look, so be cautious!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBJCA-1310) NPE when validating database connection (and the validation failed) if connection pool statistics is enabled
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1310?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1310:
-----------------------------------
Workaround Description: Use mcp="org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool"
Workaround: Workaround Exists
Priority: Critical (was: Major)
Thanks for the file. Could you rerun with the Tracer on (<tracer enabled="true">) ? You will see TRACE statements with IJTRACER in them. Also attach the file instead of pasting into comments.
We need to figure out where the getConnectionListener() becomes null
> NPE when validating database connection (and the validation failed) if connection pool statistics is enabled
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1310
> URL: https://issues.jboss.org/browse/JBJCA-1310
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.2.Final, 1.2.6.Final
> Reporter: Hugh Nguyen
> Assignee: Jesper Pedersen
> Priority: Critical
>
> - An xa-datasource connection pool is configured with: statistic-enabled=true, validate-on-match=true
> - When validation failed, after the failure, the following is logged:
> {code}
> 2016-02-10 12:23:12,580 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Sched1_Worker-13) IJ000621: Destroying connection that could not be validated: null
> {code}
> - This appears to come from SemaphoreConcurrentLinkedDequeManagedConnectionPool.java, line 436:
> {code}
> log.destroyingConnectionNotValidated(clw.getConnectionListener());
> {code}
> - So apparently clw.getConnectionListener() is null at this point, causing line 441/442 to throw NPE, if statistics is enabled:
> {code}
> pool.getInternalStatistics().deltaTotalPoolTime(lastUsed - clw.getConnectionListener().getLastReturnedTime());
> {code}
> - NPE is caught by the catch clause, and line 456 write the following to the log:
> {code}
> 2016-02-10 12:23:12,580 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Sched1_Worker-13) IJ000613: Throwable while trying to match managed connection, destroying connection: null: java.lang.NullPointerException
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:441)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:708)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:607)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> {code}
> - However, this catch clause try to do the same thing that cause the NPE in line 461/462
> {code}
> pool.getInternalStatistics().deltaTotalPoolTime(lastUsed - clw.getConnectionListener().getLastReturnedTime());
> {code}
> - And finally this NPE is throw all the way out to the user of the connection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-869) Cache Store descriptor specifies that properties max-occurs = 1
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-869?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on WFLY-869:
-------------------------------------
Although, let me link an issue: WFCORE-320 which is to implement cardinality checking properly.
> Cache Store descriptor specifies that properties max-occurs = 1
> ---------------------------------------------------------------
>
> Key: WFLY-869
> URL: https://issues.jboss.org/browse/WFLY-869
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: NadirX
> Assignee: Radoslav Husar
> Priority: Minor
>
> Querying the descriptor for the Infinispan subsystem reveals that the <property> sub-element of the <store> element has been specified at max-occurs = 1, while it should be unlimited
> property" => {
> "description" => "A cache store property with name and value.",
> "min-occurs" => 0,
> "max-occurs" => 1,
> "model-description" => {"*" => {
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-869) Cache Store descriptor specifies that properties max-occurs = 1
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-869?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar closed WFLY-869.
-------------------------------
Resolution: Out of Date
This is very out of date.
# there is no such thing as min/max-occurs (I am not even sure if it made it to public EAP release as this was dropped early on)
# the attribute to control properties is:
{code}[standalone@localhost:9990 /] /subsystem=infinispan/cache-container=web/distributed-cache=dist/store=file/:write-attribute(name=properties,value=[a=b]{code}
> Cache Store descriptor specifies that properties max-occurs = 1
> ---------------------------------------------------------------
>
> Key: WFLY-869
> URL: https://issues.jboss.org/browse/WFLY-869
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: NadirX
> Assignee: Radoslav Husar
> Priority: Minor
>
> Querying the descriptor for the Infinispan subsystem reveals that the <property> sub-element of the <store> element has been specified at max-occurs = 1, while it should be unlimited
> property" => {
> "description" => "A cache store property with name and value.",
> "min-occurs" => 0,
> "max-occurs" => 1,
> "model-description" => {"*" => {
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6257) Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6257?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6257:
--------------------------------
Description: Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. (was: Currently the way the JTAEnvironmentBean works is to force a list of filters. It would be useful for a user to be able to override those in certain situations.)
> Allow Narayanas list of XAOrphanFilters to include a check of the transaction status manager
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-6257
> URL: https://issues.jboss.org/browse/WFLY-6257
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
>
> Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months