[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
14 years, 2 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
14 years, 2 months
[JBoss JIRA] Created: (EJBTHREE-1330) EJB timer service should use a thread pool to avoid OOM
by Galder Zamarreno (JIRA)
EJB timer service should use a thread pool to avoid OOM
-------------------------------------------------------
Key: EJBTHREE-1330
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1330
Project: EJB 3.0
Issue Type: Bug
Components: pool
Affects Versions: AS 4.2.2.GA
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
The default EJB timer service used by the EJB3 layer is based on
org.jboss.ejb3.timerservice.jboss.JBossTimerServiceFactory which delegates
to the standard org.jboss.ejb.txtimer.EJBTimerService.
For EJB3 beans using the EJB timer service the thread local pool should not be used.
Since the current EJB timer service creates a new thread for each timer being created, the
thread local pool will create a matching instance of the bean for that thread. Thus the number
of active instances in total can effectively grow unchecked and thus an OOM will occur.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-3583) CLI: data-source add command argument jndi-name not mandatory
by Dominik Pospisil (JIRA)
Dominik Pospisil created AS7-3583:
-------------------------------------
Summary: CLI: data-source add command argument jndi-name not mandatory
Key: AS7-3583
URL: https://issues.jboss.org/browse/AS7-3583
Project: Application Server 7
Issue Type: Bug
Components: CLI
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Alexey Loubyansky
The data-source add command argument "jndi-name" is not mandatory. The CLI allows exection of data-source add command without specifying jndi name. Enabling such data-source fails.
[standalone@localhost:9999 /] data-source add --name=TestDS2 --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1
[standalone@localhost:9999 /] data-source enable --name=TestDS2
JBAS010436: Failed to create DataSource instance for [{
"operation" => "enable",
"address" => [
("subsystem" => "datasources"),
("data-source" => "TestDS2")
],
"persistent" => undefined
}]
reason: IJ010068: Missing required attribute jndi-name in org.jboss.as.connector.subsystems.datasources.ModifiableDataSource
--
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
14 years, 2 months
[JBoss JIRA] (JBRULES-3355) Problems when writing rhs in Rule API
by Edson Tirelli (JIRA)
Edson Tirelli created JBRULES-3355:
--------------------------------------
Summary: Problems when writing rhs in Rule API
Key: JBRULES-3355
URL: https://issues.jboss.org/browse/JBRULES-3355
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.4.0.Beta1, 5.3.1.Final
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 5.3.2.Final, 5.4.0.Beta2
Description of problem:
There are several problems when writing rhs of a rule in Rule API:
- if you omit rhs() you 'nullend' on the end of the rule which results in
compile error
- if you put comment in rhs() like rhs("//consequences") you get
'//consequencesend' which result in compile error as well
I think there should be line delimiter behind rhs and that if rhs is omitted it
should result in empty string rather than "null".
KnowledgeDescr descr = DescrFactory.newPackage().name("org.sample")
.newRule().name("results in consequencesend")
.rhs("//consequences")
.end()
.newRule().name("results in nullend")
.lhs()
.pattern("String").end()
.end()
.end()
.getDescr();
--
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
14 years, 2 months