[JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFCORE-94:
-----------------------------------
Yes it can; after this change, enabling security manager no longer means adding the system (instead the subsystem will always be added). To test with security manager, the -secmgr flag would be given at boot, meaning both core and full can be tested with and without security manager enabled.
> Add -secmgr to startup scripts and propagate -secmgr through the domain
> -----------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-918) Web deployment metrics missing
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-918?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on WFLY-918:
-------------------------------------
It would be great the metrics provided all the information for mod_cluster integration as well, so that we can get rid of some the wrapping I had to put in here https://github.com/wildfly/wildfly/tree/master/mod_cluster/undertow/src/m...
> Web deployment metrics missing
> ------------------------------
>
> Key: WFLY-918
> URL: https://issues.jboss.org/browse/WFLY-918
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Stefan Negrea
> Assignee: Stuart Douglas
> Labels: rhq
> Fix For: 9.0.0.Beta1
>
>
> The following web deployment metrics are missing from AS7 when compared to AS5 exposed metrics:
> Clustered - True if this web application context is clustered
> Virtual Host - the virtual host with which this context is associated
> Response Time - the minimum, maximum, and average response times for requests serviced by this webapp
> Currently Active Sessions - the number of sessions that are currently active for this WAR
> Maximum Active Sessions - the maximum number of sessions that have been active for this WAR
> Created Sessions - the number of sessions created for this WAR
> Created Sessions per Minute - the number of sessions created for this WAR
> Expired Sessions - the number of expired sessions for this WAR
> Expired Sessions per Minute - the number of expired sessions for this WAR
> Rejected Sessions - the number of sessions rejected for this WAR
> Rejected Sessions per Minute - the number of sessions rejected for this WAR
> Average Session Alive Time - the average alive time of sessions for this WAR
> Max Session Alive Time - the maximum alive time of sessions for this WAR
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFCORE-94:
-----------------------------------
Security manager subsystem is not part of core, but full/web given that is part of EE.
So we cannot include that by default in testsuite / build for core.
> Add -secmgr to startup scripts and propagate -secmgr through the domain
> -----------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-2632:
---------------------------------
Workaround Description: (was: Ignore the messages, they will disappear after 1 minute (or the value of UNICAST3.conn_close_timeout).)
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.Beta1
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1887.
----------------------------
Resolution: Done
> Remove the synchronization on JChannel.class in JChannel.init
> -------------------------------------------------------------
>
> Key: JGRP-1887
> URL: https://issues.jboss.org/browse/JGRP-1887
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.5.2, 3.6
>
>
> {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources.
> This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1887 at 10/6/14 6:50 AM:
---------------------------------------------------------
h4. Solution
* Remove the synchronization around {{JChannel.init()}}
* In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport. Note that this does not affect non-shared transports.
was (Author: belaban):
h4. Solution
* Remove the synchronization around {{JChannel.init()}}
* In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport.
> Remove the synchronization on JChannel.class in JChannel.init
> -------------------------------------------------------------
>
> Key: JGRP-1887
> URL: https://issues.jboss.org/browse/JGRP-1887
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.5.2, 3.6
>
>
> {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources.
> This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1887 at 10/6/14 6:49 AM:
---------------------------------------------------------
h4. Solution
* Remove the synchronization around {{JChannel.init()}}
* In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport.
was (Author: belaban):
h4. Solution
* Remove the synchronization around {{JChannel.init()}
* In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport.
> Remove the synchronization on JChannel.class in JChannel.init
> -------------------------------------------------------------
>
> Key: JGRP-1887
> URL: https://issues.jboss.org/browse/JGRP-1887
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.5.2, 3.6
>
>
> {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources.
> This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1887:
--------------------------------
h4. Solution
* Remove the synchronization around {{JChannel.init()}
* In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport.
> Remove the synchronization on JChannel.class in JChannel.init
> -------------------------------------------------------------
>
> Key: JGRP-1887
> URL: https://issues.jboss.org/browse/JGRP-1887
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.5.2, 3.6
>
>
> {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources.
> This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years