[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 Serg Jakean19019 (JIRA)
Serg Jakean19019 created WFLY-5857:
--------------------------------------
Summary: 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
Affects Versions: 9.0.1.Final
Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha
Reporter: Serg Jakean19019
Assignee: Jason Greene
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)
10 years, 7 months
[JBoss JIRA] (WFLY-4839) annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4839?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4839:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1235627|https://bugzilla.redhat.com/show_bug.cgi?id=1235627] from POST to MODIFIED
> annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4839
> URL: https://issues.jboss.org/browse/WFLY-4839
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha4
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 10.0.0.Beta2
>
>
> {noformat}
> ### Description of problem:
> Annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true.
> Note that Servlet 3.0 specification clearly states the following:
> ~~~
> 1.6.2 Processing annotations
> In Servlet 2.5, metadata-complete only affected the scanning of annotations at
> deployment time. The notion of web-fragments did not exist in servlet 2.5. However
> in servlet 3.0 metadata-complete affects scanning of all annotations and web-
> fragments at deployment time. The version of the descriptor MUST not affect which
> annotations you scan for in a web application. An implementation of a particular
> version of the specification MUST scan for all annotations supported in that
> configuration, unless metadata-complete is specified.
> ~~~
> ### How reproducible:
> Anytime
> ### Steps to Reproduce:
> 1. Create a library jar which contains a servlet filter using @WebFilter
> 2. Put the jar under WEB-INF/lib of the web application which web.xml version is 2.3 or 2.4
> 3. Start JBoss EAP 6
> 4. Access the web application and see if the servlet filter works
> ### Actual results:
> The servlet filter is not invoked
> ### Expected results:
> The servlet filter is invoked
> ### Additional info:
> It works when the version of web.xml is 2.5 or 3.0
> [reply] [−]
> Private
> Comment 1 Masafumi Miura 2015-06-25 07:18:17 EDT
> RED HAT CONFIDENTIAL
> It looks metadata-complete is always set to true when the version of web.xml is 2.3 or 2.4 at the line 96 of web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java.
> Though Servlet 2.3/2.3 specification does not have metadata-complete attribute, Servlet 3.0 specification states the following. I think it means that the metadata-complete attribute default to false if it is not specified.
> ~~~
> 8.1 Annotations and pluggability
> if the metadata-complete attribute is not specified or is set to "false", the
> deployment tool must examine the class files of the application for annotations, and
> scan for web fragments.
> ~~~
> * web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java
> 76 public class WarMetaDataProcessor implements DeploymentUnitProcessor {
> 77
> 78 @Override
> 79 public void deploy(DeploymentPhaseContext phaseContext) throws DeploymentUnitProcessingException {
> ...
> 87 boolean isComplete = false;
> 88 WebMetaData specMetaData = warMetaData.getWebMetaData();
> 89 if (specMetaData != null) {
> 90 if (specMetaData instanceof Web25MetaData) {
> 91 isComplete |= ((Web25MetaData) specMetaData).isMetadataComplete();
> 92 } else if (specMetaData instanceof Web30MetaData) {
> 93 isComplete |= ((Web30MetaData) specMetaData).isMetadataComplete();
> 94 } else {
> 95 // Any web.xml 2.4 or earlier deployment is metadata complete
> 96 isComplete = true;
> 97 }
> 98 }
> 99
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-2880) DsXmlDeploymentInstallProcessor passes wrong ManagementResourceRegistration to DataSourceStatisticsListener
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2880?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2880:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1245363|https://bugzilla.redhat.com/show_bug.cgi?id=1245363] from POST to MODIFIED
> DsXmlDeploymentInstallProcessor passes wrong ManagementResourceRegistration to DataSourceStatisticsListener
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2880
> URL: https://issues.jboss.org/browse/WFLY-2880
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 8.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Final
>
>
> Unlike AbstractDataSourceAdd, which passes an override registration into DataSourceStatisticsListener, DsXmlDeploymentInstallProcessor passes in the main registration.
> I believe this is the cause of the following stuff in the logs Tomaz Cerar saw when messing about with the WildFly quickstarts:
> {noformat}
> 22:50:05,945 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener@1281d4a" failed: java.lang.IllegalArgumentException:
> JBAS014809: A node is already registered at '(deployment => *)(subsystem => datasources)(data-source => *)(statistics => jdbc)'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:145) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBMESSAGING-1958) Backward compatibility issue caused by recent fixes
by Yong Hao Gao (JIRA)
Yong Hao Gao created JBMESSAGING-1958:
-----------------------------------------
Summary: Backward compatibility issue caused by recent fixes
Key: JBMESSAGING-1958
URL: https://issues.jboss.org/browse/JBMESSAGING-1958
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Remoting
Affects Versions: 1.4.8.SP11, 1.4.0.SP3.CP14
Reporter: Yong Hao Gao
Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
In the following Jiras:
https://issues.jboss.org/browse/JBMESSAGING-1851
https://issues.jboss.org/browse/JBMESSAGING-1876
We've added three more fields in ClientConnectionFactoryDelegate
private long maxRetryChangeRate;
private long retryChangeRateInterval;
private long minTimeoutProcessTime;
This will cause backward compatibility issues when JBM server talks to old clients that are not aware of those changes. To those old clients the three fields are marshalled but never read by client. This will cause marshal problems as shown in the following example stack trace:
20:08:46,052 INFO [MicroSocketClientInvoker] SocketClientInvoker[47f6473, bisocket://127.0.0.2:4457] got exception java.io.IOException
20:08:46,054 ERROR [SocketClientInvoker] Got marshalling exception, exiting
java.io.IOException
at java.io.DataInputStream.readFully(DataInputStream.java:197)
at java.io.DataInputStream.readUTF(DataInputStream.java:609)
at java.io.DataInputStream.readUTF(DataInputStream.java:564)
at org.jboss.messaging.util.Version.read(Version.java:251)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.read(ClientConnectionFactoryDelegate.java:348)
at org.jboss.jms.delegate.TopologyResult.read(TopologyResult.java:123)
at org.jboss.jms.wireformat.ConnectionFactoryGetTopologyResponse.read(ConnectionFactoryGetTopologyResponse.java:70)
at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:303)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:917)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:603)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:422)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141)
at org.jboss.remoting.Client.invoke(Client.java:1858)
at org.jboss.remoting.Client.invoke(Client.java:718)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientClusteredConnectionFactoryDelegate$getTopology$aop(ClientClusteredConnectionFactoryDelegate.java:326)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.getTopology(ClientClusteredConnectionFactoryDelegate.java)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:105)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.readObject(ClientClusteredConnectionFactoryDelegate.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1896)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1993)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1918)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at java.rmi.MarshalledObject.get(MarshalledObject.java:160)
at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:737)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:654)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jms.client.JMSClient.getFactory(JMSClient.java:147)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBMESSAGING-1958) Backward compatibility issue caused by recent fixes
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1958?page=com.atlassian.jira.... ]
Yong Hao Gao reassigned JBMESSAGING-1958:
-----------------------------------------
Assignee: Yong Hao Gao
> Backward compatibility issue caused by recent fixes
> ---------------------------------------------------
>
> Key: JBMESSAGING-1958
> URL: https://issues.jboss.org/browse/JBMESSAGING-1958
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Remoting
> Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP11
> Reporter: Yong Hao Gao
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> In the following Jiras:
> https://issues.jboss.org/browse/JBMESSAGING-1851
> https://issues.jboss.org/browse/JBMESSAGING-1876
> We've added three more fields in ClientConnectionFactoryDelegate
> private long maxRetryChangeRate;
> private long retryChangeRateInterval;
> private long minTimeoutProcessTime;
> This will cause backward compatibility issues when JBM server talks to old clients that are not aware of those changes. To those old clients the three fields are marshalled but never read by client. This will cause marshal problems as shown in the following example stack trace:
> 20:08:46,052 INFO [MicroSocketClientInvoker] SocketClientInvoker[47f6473, bisocket://127.0.0.2:4457] got exception java.io.IOException
> 20:08:46,054 ERROR [SocketClientInvoker] Got marshalling exception, exiting
> java.io.IOException
> at java.io.DataInputStream.readFully(DataInputStream.java:197)
> at java.io.DataInputStream.readUTF(DataInputStream.java:609)
> at java.io.DataInputStream.readUTF(DataInputStream.java:564)
> at org.jboss.messaging.util.Version.read(Version.java:251)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.read(ClientConnectionFactoryDelegate.java:348)
> at org.jboss.jms.delegate.TopologyResult.read(TopologyResult.java:123)
> at org.jboss.jms.wireformat.ConnectionFactoryGetTopologyResponse.read(ConnectionFactoryGetTopologyResponse.java:70)
> at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:303)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:917)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:603)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:422)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141)
> at org.jboss.remoting.Client.invoke(Client.java:1858)
> at org.jboss.remoting.Client.invoke(Client.java:718)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientClusteredConnectionFactoryDelegate$getTopology$aop(ClientClusteredConnectionFactoryDelegate.java:326)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.getTopology(ClientClusteredConnectionFactoryDelegate.java)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:105)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.readObject(ClientClusteredConnectionFactoryDelegate.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1896)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1993)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1918)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at java.rmi.MarshalledObject.get(MarshalledObject.java:160)
> at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:737)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:654)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jms.client.JMSClient.getFactory(JMSClient.java:147)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months