[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from POST to MODIFIED
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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, 2 months
[JBoss JIRA] (WFLY-2352) Domain controller fails to restart due to an inconsistent rollback of a redeploy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2352:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763] from POST to MODIFIED
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
> Key: WFLY-2352
> URL: https://issues.jboss.org/browse/WFLY-2352
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
>
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> {code}
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.
--
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, 2 months
[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin... ]
Ron Sigal updated JBREM-1307:
-----------------------------
Attachment: jboss-remoting.jar
jboss-remoting-src.jar
This fix will be in release 2.5.4.SP5. I'm attaching a jboss-remoting.jar in case someone wants to try it.
> TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
> --------------------------------------------------------------------------
>
> Key: JBREM-1307
> URL: https://issues.jboss.org/browse/JBREM-1307
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.2.3.SP2
> Environment: JBoss EAP 4.3.0 CP08 and CP10
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Labels: messaging
> Attachments: jboss-remoting-src.jar, jboss-remoting.jar
>
>
> In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException.
> When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked.
> This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629
> Specifically, in a thread dump you will see:
> "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362)
> - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80)
> at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57)
> at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
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, 2 months
[JBoss JIRA] (LOGMGR-86) Create an exception filter
by James Perkins (JIRA)
James Perkins created LOGMGR-86:
-----------------------------------
Summary: Create an exception filter
Key: LOGMGR-86
URL: https://issues.jboss.org/browse/LOGMGR-86
Project: JBoss Log Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: James Perkins
Assignee: James Perkins
Priority: Optional
For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be used.
--
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, 2 months
[JBoss JIRA] (WFLY-1702) Investigate module wiring consistency at build time
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1702?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reassigned WFLY-1702:
------------------------------------
Assignee: (was: Thomas Diesler)
> Investigate module wiring consistency at build time
> ---------------------------------------------------
>
> Key: WFLY-1702
> URL: https://issues.jboss.org/browse/WFLY-1702
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Thomas Diesler
> Fix For: 8.0.0.CR1
>
>
> Due to the use of human wiring decisions it is possible that the initial modules wiring setup is incomplete/inconsistent. Various inconsistencies can occur
> * There are code paths in a module that require a class load for which there is no dependency defined
> * Modules define (stale) dependencies that are never used
> * Modules define dependencies that are inconsistent in the class space
--
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, 2 months
[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
David Tombs created DROOLS-319:
----------------------------------
Summary: "Unknown boolean operator" RuntimeException
Key: DROOLS-319
URL: https://issues.jboss.org/browse/DROOLS-319
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: Windows 8, java version "1.7.0_40"
Reporter: David Tombs
Assignee: Mark Proctor
Steps to reproduce:
# Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
# Execute the rule against a few objects.
Actual Result:
An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
Expected Result:
Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
--
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, 2 months
[JBoss JIRA] (WFLY-1774) Determine if Jandex can be used to optimize CDI + Bean Validation integration for method validation
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-1774?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-1774:
----------------------------------
As discussed with Hardy, the two tasks described in this JIRA are low priority. For now, I’ve done an initial investigation around some questions that have been raised and I’m adding my findings below for future reference if/when these tasks are revisited.
\\
\\
*How could we get the Jandex index for a deployment?*
The Jandex index is available as a deployment unit attachment (e.g., {{deploymentUnit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX)}}).
\\
\\
*How could we pass the Jandex index to the Hibernate Validator CDI portable extension?*
Currently, CDI portable extensions get loaded by [WeldPortableExtensions#tryRegisterExtension|https://github.com/wildfly/wi...]. Note that this instantiates extensions using the default no-arg constructor. One option would be to add a new constructor to the Hibernate Validator CDI portable extension that takes a {{org.jboss.as.server.deployment.annotation.CompositeIndex}} as an argument and then modify {{WeldPortableExtensions#tryRegisterExtension}} to pass the Jandex index from the deployment unit attachment when registering this particular extension. This option would allow us to make use of the existing portable extension instead of creating a new one specifically for WildFly. This way, the portable extension can still be used outside of WildFly without Jandex via the existing no-arg constructor.
\\
\\
*How could we find subtypes of a given class using Jandex?*
All known subclasses (even non-direct ones) of a class can be found via {{CompositeIndex#getAllKnownSubclasses}}. All known classes that implement an interface (directly or indirectly) can be found via {{CompositeIndex#getAllKnownImplementors}}. Note that both of these methods return a set of {{org.jboss.jandex.ClassInfo}} objects. When the portable extension’s {{processAnnotatedType}} method is fired for a particular class, the high level idea here would be to get all known subclasses / all known classes that implement it and register the appropriate method validation interceptor bindings for these classes as well. This would allow us to avoid having to specify @ValidateOnExecution(IMPLICIT).
\\
\\
*To speed up constraint metadata retrieval, we need to be able to make use of the Jandex index to find classes that contain annotations that are themselves annotated with {{@Constraint}}. How could we do this?*
Note that if an annotation class is not part of the deployment, it won’t be part of the Jandex index for that deployment. This means that it’s _not_ possible to just do the following:
# Use the Jandex index to find all classes (annotation classes) annotated with {{@Constraint}}
# Use the Jandex index to find all classes annotated with the results from (1)
Instead, given a particular class, one option would be to do something similar to what Weld currently does with {{@WithAnnotations}}. In particular, to determine if a class contains an annotation specified via {{@WithAnnotations}}, Weld first looks for the class in the Jandex index. If the class is not found, Weld falls back to using reflection. Otherwise, Weld gets the annotations for the class from the Jandex index and tries to find the specified annotation. If the specified annotation isn't found directly, Weld then iterates over all of the annotations from the class to check if any of the annotation classes themselves are annotated with the specified annotation. Again, if the annotation class isn't in the Jandex index, Weld falls back to using reflection (see [WeldAnnotationDiscovery#containsAnnotation|https://github.com/wildfly/wil...]). We could do something similar to this, i.e., try to use the Jandex index when possible and fall back to using reflection when necessary. Since it’s not possible to eliminate the use of reflection completely, we should also determine to what extent this solution will actually speed up constraint metadata retrieval.
> Determine if Jandex can be used to optimize CDI + Bean Validation integration for method validation
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-1774
> URL: https://issues.jboss.org/browse/WFLY-1774
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha3
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> For CDI + Bean Validation integration for method validation, we're making use of the Hibernate Validator CDI portable extension. We can try to optimize this portable extension by making use of the Jandex index. In particular, we can:
> 1) Determine if Jandex can be used for subtype retrieval to avoid having to specify @ValidateOnExecution(IMPLICIT)
> 2) Determine if Jandex can be used to speed up constraint metadata retrieval
--
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, 2 months