[JBoss JIRA] (AS7-3589) CLONE - Distributable deployment in a clustering env. in standalone mode with 2 nodes installed in different datacenter does not wokr as expected
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/AS7-3589?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro resolved AS7-3589.
-------------------------------
Resolution: Rejected
Your expectation is incorrect.
In AS7, multi-node deployment is done via the domain controller. Read domain management documentation for details.
> CLONE - Distributable deployment in a clustering env. in standalone mode with 2 nodes installed in different datacenter does not wokr as expected
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3589
> URL: https://issues.jboss.org/browse/AS7-3589
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.0.CR1b
> Environment: RHEL 6, JBoss EAP 6 DR12
> Reporter: Serge Emmanuel Pagop
> Assignee: Paul Ferraro
> Fix For: 7.1.1.Final
>
>
> I create multiple IP Addresses on a single NIC for this use case.
> Use-Case: Clustering in Standalone mode with 2 nodes installed in different Datacenter
> Action: deployment of a distributable web application in the node 1 from datacenter 1
> Expectation: consequence should be also the deployment of the distributable application in the running node2 from datacenter 2
> Result: no deployment of application in the running node2 from datacenter2
> Info: find the web application example as attach
> All the steps:
> 1) from datacenter 1
> + Start node1 in Standalone mode from datacenter with IP 192.168.178.31
> $EAP6_HOME/bin>./standalone.sh -c=standalone-ha.xml -b=192.168.178.31 -bmanagement=192.168.178.31 -Djboss.node.name=node1
> 2)from datacenter 2
> + Start node2 in standalone mode from datacenter with IP 192.168.178.32
> $EAP6_HOME/bin>./standalone.sh -c=standalone-ha.xml -b=192.168.178.32 -bmanagement=192.168.178.32 -Djboss.node.name=node2
> 3)from datacenter 1
> + deploy a distributable application in the running standalone node1 - copy the application into the directory $EAP6_HOME/standalone/deployments
> during the deployment server log shows this infos:
> - Start Server log infos
> 22:26:28,506 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "version3.war"
> 22:26:29,285 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) send buffer of socket java.net.DatagramSocket@40993028 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 22:26:29,286 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) receive buffer of socket java.net.DatagramSocket@40993028 was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 22:26:29,286 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) send buffer of socket java.net.MulticastSocket@928b33a was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 22:26:29,288 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) receive buffer of socket java.net.MulticastSocket@928b33a was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 22:26:29,303 INFO [stdout] (MSC service thread 1-1)
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) -------------------------------------------------------------------
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) GMS: address=node1/web, cluster=web, physical address=192.168.178.31:55200
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) -------------------------------------------------------------------
> 22:26:31,359 INFO [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-4) JBAS010207: Number of cluster members: 1
> 22:26:31,781 WARN [org.infinispan.config.ConfigurationValidatingVisitor] (MSC service thread 1-4) ISPN000152: Passivation configured without a valid eviction policy. This could mean that the cache store will never get used unless code calls Cache.evict() manually.
> 22:26:31,971 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078: Starting JGroups Channel
> 22:26:31,972 WARNING [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (MSC service thread 1-4) Channel Muxer already has a default up handler installed (org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler@6b7fb9d5) but now it is being overridden
> 22:26:31,972 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094: Received new cluster view: [node1/web|0] [node1/web]
> 22:26:31,973 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079: Cache local address is node1/web, physical addresses are [192.168.178.31:55200]
> 22:26:31,976 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0.CR1
> 22:26:32,077 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-1) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 22:26:32,145 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 22:26:32,193 INFO [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010301: Started registry cache from web container
> 22:26:32,193 INFO [org.jboss.as.clustering] (MSC service thread 1-4) JBAS010301: Started repl cache from web container
> 22:26:32,347 INFO [org.jboss.web] (MSC service thread 1-4) registering web context: /version3
> 22:26:32,402 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "version3.war"
> - End Server log infos
> 4) From datacenter 2
> No action deployment in node2
> - Start Server log info
> ...
> 22:25:36,179 INFO [org.jboss.as.remoting] (MSC service thread 1-4) Listening on /192.168.178.32:9999
> 22:25:36,233 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /NotBackedUp/spagop/EAP6_TRAINING/my-labs/clustering/standalone-lab/node2/jboss-eap-6.0/standalone/deployments
> 22:25:36,986 INFO [org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 8096ms - Started 152 of 259 services (102 services are passive or on-demand)
> - End Server log info
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-3291) EnversIntegrator is always detected by default while initializing Serviceregistry using Native Hibernate API causing a MappingException even when Envers is not used
by Madhumita Sadhukhan (JIRA)
Madhumita Sadhukhan created AS7-3291:
----------------------------------------
Summary: EnversIntegrator is always detected by default while initializing Serviceregistry using Native Hibernate API causing a MappingException even when Envers is not used
Key: AS7-3291
URL: https://issues.jboss.org/browse/AS7-3291
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate, Test Suite
Affects Versions: 7.1.0.CR1
Reporter: Madhumita Sadhukhan
Assignee: Strong Liu
Please find the hibernate native api tests located at :
https://github.com/madhumita12/jboss-as/tree/master/testsuite/integration...
The tests are working fine with a workaround I have applied to them,hence I would like to request you to run the HibernateNativeAPITransactionTestCase locally to see the issue I have been mentioning before.
Also , please comment the workaround as follows before running the test in order to hit around the issue:
In file SFSBHibernateTransaction please comment:
// configuration.setProperty("hibernate.listeners.envers.autoRegister", "false");
I am simply initialising BootstrapServiceRegistryBuilder and then passing the configuration properties to it to initialize the ServiceRegistry.
I am not using any AuditListner or @Audited anywhere in my configuration/code.
However when I initialize ServiceRegistry it by default AUTORegisters/detects the EnversIntegrator which tries to initialise AuditListner via Auditconfiguration and crashes.
The workaround to this is to set the AUTO_REGISTER in EnversIntegrator to false as above.
Stacktrace:
... 139 more
Caused by: org.hibernate.MappingException: Unable to create AuditStrategy[org.hibernate.envers.strategy.DefaultAuditStrategy] instance.
at org.hibernate.envers.configuration.AuditConfiguration.initializeAuditStrategy(AuditConfiguration.java:114)
at org.hibernate.envers.configuration.AuditConfiguration.<init>(AuditConfiguration.java:101)
at org.hibernate.envers.configuration.AuditConfiguration.getFor(AuditConfiguration.java:135)
at org.hibernate.envers.event.EnversIntegrator.integrate(EnversIntegrator.java:63)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:295) [hibernate-core-4.0.0.Final.jar:4.0.0.Final]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1737) [hibernate-core-4.0.0.Final.jar:4.0.0.Final]
at org.jboss.as.test.integration.hibernate.SFSBHibernateTransaction.setupConfig(SFSBHibernateTransaction.java:81) [beans.jar:]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-2189) Revisit the jgroups management configuration
by Heiko Braun (Created) (JIRA)
Revisit the jgroups management configuration
--------------------------------------------
Key: AS7-2189
URL: https://issues.jboss.org/browse/AS7-2189
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 7.1.0.CR1
This doesn't look very reasonable to me:
{noformat}
[domain@localhost:9999 /] /profile=ha/subsystem=jgroups/stack=tcp:read-resource
{
"outcome" => "success",
"result" => {
"protocol" => [
{
"type" => "MPING",
"socket-binding" => "jgroups-mping"
},
{"type" => "MERGE2"},
{
"type" => "FD_SOCK",
"socket-binding" => "jgroups-tcp-fd"
},
{"type" => "FD"},
{"type" => "VERIFY_SUSPECT"},
{"type" => "BARRIER"},
{"type" => "pbcast.NAKACK"},
{"type" => "UNICAST"},
{"type" => "pbcast.STABLE"},
{"type" => "VIEW_SYNC"},
{"type" => "pbcast.GMS"},
{"type" => "UFC"},
{"type" => "MFC"},
{"type" => "FRAG2"},
{"type" => "pbcast.STREAMING_STATE_TRANSFER"},
{"type" => "pbcast.FLUSH"}
],
"transport" => {
"type" => "TCP",
"socket-binding" => "jgroups-tcp",
"diagnostics-socket-binding" => "jgroups-diagnostics"
}
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-3294) JSF Exception - Failed to parse the expression [#{cc.attrs.for}]
by Lincoln Baxter III (JIRA)
Lincoln Baxter III created AS7-3294:
---------------------------------------
Summary: JSF Exception - Failed to parse the expression [#{cc.attrs.for}]
Key: AS7-3294
URL: https://issues.jboss.org/browse/AS7-3294
Project: Application Server 7
Issue Type: Bug
Components: JSF
Affects Versions: 7.1.0.CR1b
Environment: Ubuntu Linux, Fedora, Java 6
Reporter: Lincoln Baxter III
Assignee: Stan Silvert
So I've run OCPsoft SocialPM ( https://github.com/ocpsoft/socialpm/ ) on both AS 7.1.0.CR1b and AS7 GitHub head, both of them get the following error when going to the signup page:
(From Ken Finnigan)
{code}21:53:35,494 WARN [org.jboss.solder.exception.control.log] (http--127.0.0.1-8080-2) No handlers found for exception javax.faces.view.facelets.TagAttributeException: /resources/ocpcommon/message.xhtml @46,61 for="#{cc.attrs.for}" Failed to parse the expression [#{cc.attrs.for}]{code}
I've attached the entire server log for AS7 Head for reference.
I've confirmed it worked with AS 7.0.2.Final, so it looks like a regression. I've taken a look at the JSF modules provided in AS7, 7.0.2 provides jsf-api-1.2_15-jbossorg-1.jar, whereas 7.1.0.CR1b and Head provides jsf-api-1.2_15-jbossorg-2.jar. I haven't had a chance to delve deeper into what discrepancies there might be between the two JSF versions yet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (AS7-1787) Fix JGroups description providers for the improved validation in jboss-as-subsystem-test
by Kabir Khan (JIRA)
Fix JGroups description providers for the improved validation in jboss-as-subsystem-test
----------------------------------------------------------------------------------------
Key: AS7-1787
URL: https://issues.jboss.org/browse/AS7-1787
Project: Application Server 7
Issue Type: Feature Request
Components: OSGi
Reporter: Kabir Khan
Assignee: Thomas Diesler
Fix For: 7.1.0.Alpha1
I am adding some more validation of the model. This will be committed to upstream in the next few days. To make the security tests pass I had to override AdditionalInitialization.getModelValidationConfiguration() as follows:
{code}
@Override
protected ValidationConfiguration getModelValidationConfiguration() {
return null;
}
{code}
Returning null basically turns off validation of the providers. These are the errors that happen (this might change a bit before I commit the final version of the validation stuff):
{code}
VALIDATION ERRORS IN MODEL:
Invalid key 'attributes' found for child type 'configuration' @[("subsystem" => "osgi")]
No value-type for type=OBJECT {"description" => "The configuration data associated with the PID.","type" => OBJECT,"required" => true,"acces
s-type" => "read-only","storage" => "configuration"} for attribute 'entries'[
("subsystem" => "osgi"),
("configuration" => "*")
]
No value-type for type=OBJECT {"description" => "The configuration data associated with the PID.","type" => OBJECT,"required" => true} for o
peration parameter 'add.entries' @[
("subsystem" => "osgi"),
("configuration" => "*")
]
Invalid key 'attributes' found for child type 'property' @[("subsystem" => "osgi")]
Invalid key 'attributes' found for child type 'module' @[("subsystem" => "osgi")]
{code}
The work in progress lives at https://github.com/kabir/jboss-as/tree/subsystem-test-model-fixes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (AS7-1788) Fix Infinispan description providers for the improved validation in jboss-as-subsystem-test
by Kabir Khan (JIRA)
Fix Infinispan description providers for the improved validation in jboss-as-subsystem-test
-------------------------------------------------------------------------------------------
Key: AS7-1788
URL: https://issues.jboss.org/browse/AS7-1788
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Reporter: Kabir Khan
Assignee: Paul Ferraro
Fix For: 7.1.0.Alpha1
I added a test called JGroupsSubsystemTest which uses our subsystem testing framework which attempts to validate the description providers, this will be committed to upstream in the next few days.
To make the tests pass I had to override AdditionalInitialization.getModelValidationConfiguration() as follows:
{code}
@Override
protected ValidationConfiguration getModelValidationConfiguration() {
return null;
}
{code}
Returning null basically turns off validation of the providers. What I have added is a minimum of what is required for subsystem testing, the test framework allows you to do a lot of other stuff, see the jmx subsystem test for some examples.
The wip lives at https://github.com/kabir/jboss-as/tree/subsystem-test-model-fixes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-3589) CLONE - Distributable deployment in a clustering env. in standalone mode with 2 nodes installed in different datacenter does not wokr as expected
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/AS7-3589?page=com.atlassian.jira.plugin.s... ]
Paul Gier moved JBPAPP-8036 to AS7-3589:
----------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-3589 (was: JBPAPP-8036)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.0.CR1b
(was: EAP 6.0.0 DR 12)
Component/s: Clustering
(was: Clustering)
Security: (was: JBoss Internal)
Fix Version/s: 7.1.1.Final
(was: EAP 6.0.0 ER 1)
Docs QE Status: (was: NEW)
> CLONE - Distributable deployment in a clustering env. in standalone mode with 2 nodes installed in different datacenter does not wokr as expected
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3589
> URL: https://issues.jboss.org/browse/AS7-3589
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.0.CR1b
> Environment: RHEL 6, JBoss EAP 6 DR12
> Reporter: Serge Emmanuel Pagop
> Fix For: 7.1.1.Final
>
>
> I create multiple IP Addresses on a single NIC for this use case.
> Use-Case: Clustering in Standalone mode with 2 nodes installed in different Datacenter
> Action: deployment of a distributable web application in the node 1 from datacenter 1
> Expectation: consequence should be also the deployment of the distributable application in the running node2 from datacenter 2
> Result: no deployment of application in the running node2 from datacenter2
> Info: find the web application example as attach
> All the steps:
> 1) from datacenter 1
> + Start node1 in Standalone mode from datacenter with IP 192.168.178.31
> $EAP6_HOME/bin>./standalone.sh -c=standalone-ha.xml -b=192.168.178.31 -bmanagement=192.168.178.31 -Djboss.node.name=node1
> 2)from datacenter 2
> + Start node2 in standalone mode from datacenter with IP 192.168.178.32
> $EAP6_HOME/bin>./standalone.sh -c=standalone-ha.xml -b=192.168.178.32 -bmanagement=192.168.178.32 -Djboss.node.name=node2
> 3)from datacenter 1
> + deploy a distributable application in the running standalone node1 - copy the application into the directory $EAP6_HOME/standalone/deployments
> during the deployment server log shows this infos:
> - Start Server log infos
> 22:26:28,506 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "version3.war"
> 22:26:29,285 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) send buffer of socket java.net.DatagramSocket@40993028 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 22:26:29,286 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) receive buffer of socket java.net.DatagramSocket@40993028 was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 22:26:29,286 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) send buffer of socket java.net.MulticastSocket@928b33a was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 22:26:29,288 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) receive buffer of socket java.net.MulticastSocket@928b33a was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 22:26:29,303 INFO [stdout] (MSC service thread 1-1)
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) -------------------------------------------------------------------
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) GMS: address=node1/web, cluster=web, physical address=192.168.178.31:55200
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) -------------------------------------------------------------------
> 22:26:31,359 INFO [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-4) JBAS010207: Number of cluster members: 1
> 22:26:31,781 WARN [org.infinispan.config.ConfigurationValidatingVisitor] (MSC service thread 1-4) ISPN000152: Passivation configured without a valid eviction policy. This could mean that the cache store will never get used unless code calls Cache.evict() manually.
> 22:26:31,971 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078: Starting JGroups Channel
> 22:26:31,972 WARNING [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (MSC service thread 1-4) Channel Muxer already has a default up handler installed (org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler@6b7fb9d5) but now it is being overridden
> 22:26:31,972 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094: Received new cluster view: [node1/web|0] [node1/web]
> 22:26:31,973 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079: Cache local address is node1/web, physical addresses are [192.168.178.31:55200]
> 22:26:31,976 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0.CR1
> 22:26:32,077 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-1) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 22:26:32,145 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 22:26:32,193 INFO [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010301: Started registry cache from web container
> 22:26:32,193 INFO [org.jboss.as.clustering] (MSC service thread 1-4) JBAS010301: Started repl cache from web container
> 22:26:32,347 INFO [org.jboss.web] (MSC service thread 1-4) registering web context: /version3
> 22:26:32,402 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "version3.war"
> - End Server log infos
> 4) From datacenter 2
> No action deployment in node2
> - Start Server log info
> ...
> 22:25:36,179 INFO [org.jboss.as.remoting] (MSC service thread 1-4) Listening on /192.168.178.32:9999
> 22:25:36,233 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /NotBackedUp/spagop/EAP6_TRAINING/my-labs/clustering/standalone-lab/node2/jboss-eap-6.0/standalone/deployments
> 22:25:36,986 INFO [org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 8096ms - Started 152 of 259 services (102 services are passive or on-demand)
> - End Server log info
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (AS7-3589) CLONE - Distributable deployment in a clustering env. in standalone mode with 2 nodes installed in different datacenter does not wokr as expected
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/AS7-3589?page=com.atlassian.jira.plugin.s... ]
Paul Gier reassigned AS7-3589:
------------------------------
Assignee: Paul Ferraro
> CLONE - Distributable deployment in a clustering env. in standalone mode with 2 nodes installed in different datacenter does not wokr as expected
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3589
> URL: https://issues.jboss.org/browse/AS7-3589
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.0.CR1b
> Environment: RHEL 6, JBoss EAP 6 DR12
> Reporter: Serge Emmanuel Pagop
> Assignee: Paul Ferraro
> Fix For: 7.1.1.Final
>
>
> I create multiple IP Addresses on a single NIC for this use case.
> Use-Case: Clustering in Standalone mode with 2 nodes installed in different Datacenter
> Action: deployment of a distributable web application in the node 1 from datacenter 1
> Expectation: consequence should be also the deployment of the distributable application in the running node2 from datacenter 2
> Result: no deployment of application in the running node2 from datacenter2
> Info: find the web application example as attach
> All the steps:
> 1) from datacenter 1
> + Start node1 in Standalone mode from datacenter with IP 192.168.178.31
> $EAP6_HOME/bin>./standalone.sh -c=standalone-ha.xml -b=192.168.178.31 -bmanagement=192.168.178.31 -Djboss.node.name=node1
> 2)from datacenter 2
> + Start node2 in standalone mode from datacenter with IP 192.168.178.32
> $EAP6_HOME/bin>./standalone.sh -c=standalone-ha.xml -b=192.168.178.32 -bmanagement=192.168.178.32 -Djboss.node.name=node2
> 3)from datacenter 1
> + deploy a distributable application in the running standalone node1 - copy the application into the directory $EAP6_HOME/standalone/deployments
> during the deployment server log shows this infos:
> - Start Server log infos
> 22:26:28,506 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "version3.war"
> 22:26:29,285 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) send buffer of socket java.net.DatagramSocket@40993028 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 22:26:29,286 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) receive buffer of socket java.net.DatagramSocket@40993028 was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 22:26:29,286 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) send buffer of socket java.net.MulticastSocket@928b33a was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 22:26:29,288 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-1) receive buffer of socket java.net.MulticastSocket@928b33a was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 22:26:29,303 INFO [stdout] (MSC service thread 1-1)
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) -------------------------------------------------------------------
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) GMS: address=node1/web, cluster=web, physical address=192.168.178.31:55200
> 22:26:29,304 INFO [stdout] (MSC service thread 1-1) -------------------------------------------------------------------
> 22:26:31,359 INFO [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-4) JBAS010207: Number of cluster members: 1
> 22:26:31,781 WARN [org.infinispan.config.ConfigurationValidatingVisitor] (MSC service thread 1-4) ISPN000152: Passivation configured without a valid eviction policy. This could mean that the cache store will never get used unless code calls Cache.evict() manually.
> 22:26:31,971 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078: Starting JGroups Channel
> 22:26:31,972 WARNING [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (MSC service thread 1-4) Channel Muxer already has a default up handler installed (org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler@6b7fb9d5) but now it is being overridden
> 22:26:31,972 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094: Received new cluster view: [node1/web|0] [node1/web]
> 22:26:31,973 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079: Cache local address is node1/web, physical addresses are [192.168.178.31:55200]
> 22:26:31,976 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0.CR1
> 22:26:32,077 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-1) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 22:26:32,145 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 22:26:32,193 INFO [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010301: Started registry cache from web container
> 22:26:32,193 INFO [org.jboss.as.clustering] (MSC service thread 1-4) JBAS010301: Started repl cache from web container
> 22:26:32,347 INFO [org.jboss.web] (MSC service thread 1-4) registering web context: /version3
> 22:26:32,402 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "version3.war"
> - End Server log infos
> 4) From datacenter 2
> No action deployment in node2
> - Start Server log info
> ...
> 22:25:36,179 INFO [org.jboss.as.remoting] (MSC service thread 1-4) Listening on /192.168.178.32:9999
> 22:25:36,233 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /NotBackedUp/spagop/EAP6_TRAINING/my-labs/clustering/standalone-lab/node2/jboss-eap-6.0/standalone/deployments
> 22:25:36,986 INFO [org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 8096ms - Started 152 of 259 services (102 services are passive or on-demand)
> - End Server log info
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months