[JBoss JIRA] (WFLY-4670) Term 'jacorb' is part of xml configuration file despite of fact being replaced by IIOP orb
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4670?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4670.
----------------------------
> Term 'jacorb' is part of xml configuration file despite of fact being replaced by IIOP orb
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4670
> URL: https://issues.jboss.org/browse/WFLY-4670
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Alpha1
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Minor
> Fix For: 10.0.0.Alpha2
>
>
> Implementation of ORB - JacORB is replaced by JDK ORB in WildFly 10. Neverhteless server xml configuration files contain term 'jacorb' at several places.
> Should not be word 'jacorb' removed from xml configuration and replaced by term 'iiop orb'?
> Examples of occurrence
> {code}
> <!-- TODO - only show this if the jacorb subsystem is added -->
> <interface name="unsecure">
> <!--
> ~ Used for IIOP sockets in the standard configuration.
> ~ To secure JacORB you need to setup SSL
> -->
> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
> </interface>
> {code}
> {code}
> <logger category="jacorb">
> <level name="WARN"/>
> </logger>
> <logger category="jacorb.config">
> <level name="ERROR"/>
> </logger>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5275) Connection Factory parameter disappears after code deployment
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5275?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5275.
----------------------------
> Connection Factory parameter disappears after code deployment
> -------------------------------------------------------------
>
> Key: WFLY-5275
> URL: https://issues.jboss.org/browse/WFLY-5275
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Mike Millson
> Assignee: Chao Wang
> Fix For: 10.0.0.CR1
>
>
> The min-pool-size setting in the following connection Factory disappears from domain.xml after any code deployments or change made in the console to the queues for the connection factory:
> {code}
> <connection-definition class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory" jndi-name="java:jboss/activemq/XAConnectionFactory" enabled="true" use-java-context="true" pool-name="ConnectionFactory" min-pool-size="0"></connection>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5002) Undertow mod_cluster CLI: Display node's Flushpackets, Flushwait, Ping, Smax and Ttl properties
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5002?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5002.
----------------------------
> Undertow mod_cluster CLI: Display node's Flushpackets, Flushwait, Ping, Smax and Ttl properties
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-5002
> URL: https://issues.jboss.org/browse/WFLY-5002
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Labels: mod_cluster
> Fix For: 10.0.0.Alpha6
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Display node's Flushpackets, Flushwait, Ping, Smax and Ttl properties
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
> "qa_balancer" => {"node" => {"worker-2" => {
> "load" => 89,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}},
> ...
> {noformat}
> h3. Call to action
> For any serious enterprise deployment, users need to tweak at least ping and ttl attributes and they will need to be able to see their values on Undertow mod_cluster proxy balancer CLI console per each worker.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-4624) JGroups protocol properties are not applied
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4624?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4624.
----------------------------
> JGroups protocol properties are not applied
> -------------------------------------------
>
> Key: WFLY-4624
> URL: https://issues.jboss.org/browse/WFLY-4624
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.CR1
> Reporter: Farah Juma
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Protocol properties are never applied, the check for applying properties is done on the legacy resource that only registers operation tranformation on old the old property address.
> Original report:
> ----
> When the JGroups subsystem is configured to use TCPPING, the following error occurs when deploying a distributable app:
> {code}
> 14:50:11,930 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of initial_hosts in TCPPING with original property value null and converted to null could not be assigned
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:79)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of initial_hosts in TCPPING with original property value null and converted to null could not be assigned
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:638)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:99)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:77)
> ... 5 more
> Caused by: java.lang.Exception: Property assignment of initial_hosts in TCPPING with original property value null and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:96)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:93)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:634)
> ... 7 more
> Caused by: java.lang.Exception: Conversion of initial_hosts in TCPPING with original property value null failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 17 more
> Caused by: java.lang.NullPointerException
> at java.util.StringTokenizer.<init>(StringTokenizer.java:199)
> at java.util.StringTokenizer.<init>(StringTokenizer.java:221)
> at org.jgroups.util.Util.parseCommaDelimitedHosts(Util.java:2650)
> at org.jgroups.conf.PropertyConverters$InitialHosts.convert(PropertyConverters.java:67)
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:81)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month