[JBoss JIRA] (WFLY-8216) Cannot Specify Attribute 'cluster' Within The cache-container Configuration (EAP 7.0.2)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8216?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-9067 to WFLY-8216:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8216 (was: JBEAP-9067)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 10.1.0.Final
(was: 7.0.2.GA)
> Cannot Specify Attribute 'cluster' Within The cache-container Configuration (EAP 7.0.2)
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8216
> URL: https://issues.jboss.org/browse/WFLY-8216
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Red Hat JBoss Enterprise Application Platform 7.0.2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> It seems that specifying the attribute 'cluster' within the cache-container configuration is no longer possible for EAP 7.0.2. With EAP 6.x, one could specify the 'cluster' attribute like such:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
> <transport cluster="testname" lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> </cache-container>
> Resulting in the following (log):
> INFO [stdout] (ServerService Thread Pool -- 58) GMS: address=rhel-box/testname, cluster=testname, physical address=127.0.0.1:55200
> ...
> 16:34:40,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 58) ISPN000094: Received new cluster view: [rhel-box/testname|0] [rhel-box/testname]
> It seems that this functionality is no longer in EAP 7.x. Specifying the above results in parsing errors (although the attribute 'cluster' seems valid per the Infinispan xsd).
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[224,17]
> Message: WFLYCTL0197: Unexpected attribute 'cluster' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseTransport(InfinispanSubsystemXMLReader.java:309)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseContainer(InfinispanSubsystemXMLReader.java:183)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:75)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:53)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:546)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:242)
> at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:141)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:103)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> This also seems to be the case for the latest EAP 7.0.4 release.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8216) Cannot Specify Attribute 'cluster' Within The cache-container Configuration (EAP 7.0.2)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8216?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-8216:
---------------------------------
Priority: Minor (was: Major)
> Cannot Specify Attribute 'cluster' Within The cache-container Configuration (EAP 7.0.2)
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8216
> URL: https://issues.jboss.org/browse/WFLY-8216
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Red Hat JBoss Enterprise Application Platform 7.0.2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> It seems that specifying the attribute 'cluster' within the cache-container configuration is no longer possible for EAP 7.0.2. With EAP 6.x, one could specify the 'cluster' attribute like such:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
> <transport cluster="testname" lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> </cache-container>
> Resulting in the following (log):
> INFO [stdout] (ServerService Thread Pool -- 58) GMS: address=rhel-box/testname, cluster=testname, physical address=127.0.0.1:55200
> ...
> 16:34:40,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 58) ISPN000094: Received new cluster view: [rhel-box/testname|0] [rhel-box/testname]
> It seems that this functionality is no longer in EAP 7.x. Specifying the above results in parsing errors (although the attribute 'cluster' seems valid per the Infinispan xsd).
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[224,17]
> Message: WFLYCTL0197: Unexpected attribute 'cluster' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseTransport(InfinispanSubsystemXMLReader.java:309)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseContainer(InfinispanSubsystemXMLReader.java:183)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:75)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:53)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:546)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:242)
> at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:141)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:103)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> This also seems to be the case for the latest EAP 7.0.4 release.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2160) Custom code to pick bind address
by Bela Ban (JIRA)
Bela Ban created JGRP-2160:
------------------------------
Summary: Custom code to pick bind address
Key: JGRP-2160
URL: https://issues.jboss.org/browse/JGRP-2160
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 4.1, 4.0.1
Example:
{{bind_addr="custom:com.acme.BindAddressPicker"}}.
The fully qualified name of a class implementing {{Supplier<InetAddress>}} needs to be given after "custom:".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2159) Delta view cannot be installed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2159:
---------------------------
Workaround: {{GMS.use_delta_views="false"}}
> Delta view cannot be installed
> ------------------------------
>
> Key: JGRP-2159
> URL: https://issues.jboss.org/browse/JGRP-2159
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1, 4.0.1
>
> Attachments: discarded_delta_view.log
>
>
> A DeltaView cannot be installed because the ref view-id is not the current view-id.
> Looking at the view sequence for members J, K and L:
> {noformat}
> 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J]
> 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K]
> 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K]
> 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K]
> 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L]
> 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L]
> {noformat}
> K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1.
> The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1.
> We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead.
> See the attached log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7885) Persistent calendar timer force logging for each invocation if the deployed-class has changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7885:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from ON_QA to VERIFIED
> Persistent calendar timer force logging for each invocation if the deployed-class has changed
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-7885
> URL: https://issues.jboss.org/browse/WFLY-7885
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Ingo Weiss
> Priority: Minor
> Labels: ejb, ejb3.1, timers, timerservice
> Fix For: 11.0.0.Alpha1
>
>
> It will be common to change classes which contains @Schedule timer methods.
> In case such methods are removed or renamed (for persistent calendar timers) the server will log the following warning forever for each invocation.
> WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=1a419372-d807-43d8-ac77-5be6696b022d) from its persistent state
> As this is intentional there should be a WARN message at (first) deployment time and the timer should be removed from the persistence.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months