[JBoss JIRA] (WFLY-2697) Domain Mode does not start with the IBM JDK
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2697?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2697:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1047515
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
> Key: WFLY-2697
> URL: https://issues.jboss.org/browse/WFLY-2697
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha3
> Environment: Windows (OS), IBM JDK
> Reporter: Eric Rich
> Assignee: Brian Stansberry
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times.
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller] ("host" => "master"),
> [Host Controller] ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller] at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller] at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (WFLY-2697) Domain Mode does not start with the IBM JDK
by Eric Rich (JIRA)
Eric Rich created WFLY-2697:
-------------------------------
Summary: Domain Mode does not start with the IBM JDK
Key: WFLY-2697
URL: https://issues.jboss.org/browse/WFLY-2697
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Alpha3
Environment: Windows (OS), IBM JDK
Reporter: Eric Rich
Assignee: Brian Stansberry
When starting domain mode with the IBM JDK the following is produced 3 out of 4 times.
[Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
[Host Controller] ("host" => "master"),
[Host Controller] ("server-config" => "server-one")
[Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
[Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
[Host Controller] at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
[jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
[Host Controller] at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
[Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
nal-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
[Host Controller] at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
[Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
al-redhat-1]
[Host Controller]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (WFLY-2696) management audit settings: syslog protocol is lowercase while uppercase is expected
by Tom Fonteyne (JIRA)
Tom Fonteyne created WFLY-2696:
----------------------------------
Summary: management audit settings: syslog protocol is lowercase while uppercase is expected
Key: WFLY-2696
URL: https://issues.jboss.org/browse/WFLY-2696
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.CR1
Environment: - 8.0.0 CR1 + latest code in master
- domain mode
Reporter: Tom Fonteyne
Assignee: Tom Fonteyne
Add a syslog handler to the audit settings of the management service of the domain controller, then start an instance. It fails to start with:
JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
at java.lang.Enum.valueOf(Enum.java:214)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JGRP-1765) TP: enable loopback by default and discard own multicasts
by Bela Ban (JIRA)
Bela Ban created JGRP-1765:
------------------------------
Summary: TP: enable loopback by default and discard own multicasts
Key: JGRP-1765
URL: https://issues.jboss.org/browse/JGRP-1765
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JGRP-1763) TimeService
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1763?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1763:
--------------------------------
Investigate where else this could be used. E.g. {{UNICAST3$Entry.update()}}
> TimeService
> -----------
>
> Key: JGRP-1763
> URL: https://issues.jboss.org/browse/JGRP-1763
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> New service which provides wall clock time at a coarse (configurable) granularity.
> Motivation: {{System.currentTimeMillis()}} or {{System.nanoTime()}} is sometimes called frequently, e.g. by {{TCPConnectionMap$TCPConnection.updateLastAccessed()}} or in FD/FD_ALL. This has a cost, especially when a lock is held (system calls while a lock is held cause preemption and the thread losing its time slice).
> However, the 2 examples above don't need the exact time, but an approximation of it is OK.
> GOALS:
> * Provide a time service which returns the last cached value of {{System.timeCurrentMillis()}}
> * This is a quick and efficient call
> * {{TimeService}} registers a timer task which updates its internal cached value every N milliseconds (configurable), e.g. every 500 ms
> BENEFIT:
> For example, in TCPConnection, the timestamp is updated whenever we send or receive a message from the peer. The timestamp is used to expire and close a connection (if configured), and can be updated 100'000 times a second. If the time service provided the current time in ms every 500ms, then {{System.currentTimeMillis()}} would only be called 2 times during a second instead of 100'000 times !
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JGRP-1763) TimeService
by Bela Ban (JIRA)
Bela Ban created JGRP-1763:
------------------------------
Summary: TimeService
Key: JGRP-1763
URL: https://issues.jboss.org/browse/JGRP-1763
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
New service which provides wall clock time at a coarse (configurable) granularity.
Motivation: {{System.currentTimeMillis()}} or {{System.nanoTime()}} is sometimes called frequently, e.g. by {{TCPConnectionMap$TCPConnection.updateLastAccessed()}} or in FD/FD_ALL. This has a cost, especially when a lock is held (system calls while a lock is held cause preemption and the thread losing its time slice).
However, the 2 examples above don't need the exact time, but an approximation of it is OK.
GOALS:
* Provide a time service which returns the last cached value of {{System.timeCurrentMillis()}}
* This is a quick and efficient call
* {{TimeService}} registers a timer task which updates its internal cached value every N milliseconds (configurable), e.g. every 500 ms
BENEFIT:
For example, in TCPConnection, the timestamp is updated whenever we send or receive a message from the peer. The timestamp is used to expire and close a connection (if configured), and can be updated 100'000 times a second. If the time service provided the current time in ms every 500ms, then {{System.currentTimeMillis()}} would only be called 2 times during a second instead of 100'000 times !
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (WFLY-2695) Creating named formater patterns for offline servers fail
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2695?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-2695:
--------------------------------
Workaround Description: Create the pattern before stopping the servers.
Workaround: Workaround Exists
> Creating named formater patterns for offline servers fail
> ---------------------------------------------------------
>
> Key: WFLY-2695
> URL: https://issues.jboss.org/browse/WFLY-2695
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 8.0.0.CR1
> Environment: any domain configuration
> Reporter: Matthias Berndt
> Assignee: James Perkins
>
> After adding and attaching a named formatter to an offline server starting the server fails due to an invalid logging configuration.
> server-one fails with:
> {{
> [Server:server-one] 00:08:00,214 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> [Server:server-one] ("subsystem" => "logging"),
> [Server:server-one] ("console-handler" => "CONSOLE")
> [Server:server-one] ]): java.lang.IllegalArgumentException: Formatter "TESTPATTERN" is not found
> }}
> I assume logging.properties is written too late in LoggingOperations.java
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months