[JBoss JIRA] (WFLY-6645) DriverProcessor should catch Throwable and not only Exception
by Volker Berlin (JIRA)
Volker Berlin created WFLY-6645:
-----------------------------------
Summary: DriverProcessor should catch Throwable and not only Exception
Key: WFLY-6645
URL: https://issues.jboss.org/browse/WFLY-6645
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 10.0.0.Final
Reporter: Volker Berlin
Assignee: David Lloyd
The method org.jboss.as.connector.deployers.ds.processors.DriverProcessor.deploy() should catch java.lang.Throwable instead of only java.lang.Exception because class loading can also produce Throwables of type java.lang.Error.
{noformat}
08:29:48,196 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."reporting.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."reporting.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "reporting.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
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.lang.UnsatisfiedLinkError: Unable to load library 'odbc': Native library (linux-x86/libodbc.so) not found in resource path (/home/andrek/Schreibtisch/wildfly-10.0.0.Final/jboss-modules.jar)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:277)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:403)
at com.sun.jna.Library$Handler.<init>(Library.java:147)
at com.inet.odbc.OdbcLibrary$1.<init>(OdbcLibrary.java:34)
at com.inet.odbc.OdbcLibrary.<clinit>(OdbcLibrary.java:34)
at com.inet.odbc.OdbcDriver.<clinit>(OdbcDriver.java:21)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.jboss.as.connector.deployers.ds.processors.DriverProcessor.deploy(DriverProcessor.java:65)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
08:29:48,213 ERROR [org.jboss.as.controller.management-operation] (management task-7) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "reporting")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"reporting.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"reporting.war\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"reporting.war\"
Caused by: java.lang.UnsatisfiedLinkError: Unable to load library 'odbc': Native library (linux-x86/libodbc.so) not found in resource path (/home/andrek/Schreibtisch/wildfly-10.0.0.Final/jboss-modules.jar)"}}
08:29:48,217 ERROR [org.jboss.as.server] (management task-7) WFLYSRV0021: Deploy of deployment "reporting.war" was rolled back with the following failure message:
{"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"reporting.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"reporting.war\".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment \"reporting.war\"
Caused by: java.lang.UnsatisfiedLinkError: Unable to load library 'odbc': Native library (linux-x86/libodbc.so) not found in resource path (/home/andrek/Schreibtisch/wildfly-10.0.0.Final/jboss-modules.jar)"}}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1189) Parser error doesn't point at the problematic line in case of extra double quote
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1189?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-1189:
--------------------------------------
Steps to Reproduce: See https://github.com/droolsjbpm/drools/pull/794
> Parser error doesn't point at the problematic line in case of extra double quote
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1189
> URL: https://issues.jboss.org/browse/DROOLS-1189
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Minor
>
> If you have a rule which wrongly has an extra double quote,
> {noformat}
> rule "rule1"
> when
> then
> System.out.println("1"");
> end
>
> rule "rule2"
> when
> then
> System.out.println("2");
> end
>
> rule "rule3"
> when
> then
> System.out.println("3");
> end
> {noformat}
> Drools raises parser errors like this:
> {noformat}
> [20,0]: [ERR 102] Line 20:0 mismatched input ''
> [20,0]: [ERR 102] Line 20:0 mismatched input '<eof>' in rule "rule1"
> [0,0]: Parser returned a null Package
> {noformat}
> It doesn't point at the problematic line which actually contains the extra double quote. So it's difficult for users to find the root cause (Imagine you have bunch of rules generated by decision table).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6644) Provide container managed sign on in configuration of pooled-connection-factory
by Miroslav Novak (JIRA)
Miroslav Novak created WFLY-6644:
------------------------------------
Summary: Provide container managed sign on in configuration of pooled-connection-factory
Key: WFLY-6644
URL: https://issues.jboss.org/browse/WFLY-6644
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
Currently it's not possible to configure container managed sign-on for Artemis RA in <pooled-connection-factory> in messaging-activemq subsystem. This will allow to provide authentication information when new connection to Artemis broker is created without specifying username and password when calling connectionFactory.createConnection().
Such security-domain could look like:
<security-domain name="CrashRecoveryDomain0">
<authentication>
<login-module code="ConfiguredIdentity" flag="required">
<module-option name="principal" value="crash0"/>
<module-option name="password" value="crash0"/>
<module-option name="password-stacking" value="useFirstPass"/>
<module-option name="userName" value="crash0"/>
</login-module>
</authentication>
</security-domain>
The main benefit is that username and password can be omitted when creating new connection and does not have to be hard cored in EJB/Servlet. This could be used for inbound connections as well. We should allow to specify default-principal-name which would be used for authentication. There is more info about this approach in WebLogic documentatin [1].
[1] https://docs.oracle.com/cd/E13222_01/wls/docs92/resadapter/security.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6173:
------------------------------------
To sum it up:
* undeploy does not necessarily means class unloading - it depends on JVM settings ({{-XX:MaxMetaspaceSize}} and friends for Java8)
* I've verified that after 50 deploy/undeploy cycles of the attached reproducer (and using {{-XX:MaxMetaspaceSize=128m}}):
** for WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" occurs
** for WildFly 10.1.0-SNAPSHOT (fix for WFLY-6347 merged) no OOM error occurs (metaspace is garbage collected)
After examining the heap dump I've identified the {{org.jboss.el.cache.BeanPropertiesCache}} as *the root cause*. In this case, it keeps a hard reference to the {{person.joey.test.TestClientBean}} class, thus effectively blocking the relevant {{ModuleClassLoader}} from GC. Enum values are treated similarly to static constants - i.e. it's not garbage collected unless the class loader of the owner class is. That's why {{person.joey.test.RequestType}} values remain in memory. OmniFaces only amplifies the impact - as mentioned above, it holds a reference to a BeanManager.
I think we can resolve this issue.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Fix For: 10.1.0.Final
>
> Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2068) Problems with JBOSS cluster
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2068?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2068.
--------------------------
Resolution: Rejected
As I said, I don't support such an old version.
> Problems with JBOSS cluster
> ---------------------------
>
> Key: JGRP-2068
> URL: https://issues.jboss.org/browse/JGRP-2068
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.6.10
> Reporter: Fouad Zoghlami
> Assignee: Bela Ban
> Attachments: the master.zip, the slave.zip
>
>
> We are using a JBOSS cluster for the Process Server component. One node (the master) is used for Process Workplace and a second node is used by an external application to start new process instances from the scanner input.
> Recently they encountered a problem where one of the 2 nodes started to give problems. When we look in the logs it looks like there is some kind of communication problem between the 2 nodes in the cluster. From that point it looks like the cluster is repaired, but from that point the process server on one of the two nodes begins to give problems when users try to send on workitems. It looks like the locking state is out of sync or something like that. In all situation we have been able to fix the issue by restarting jboss on both nodes and clearing the /tmp, /data and /work folders
> Please see the logs file.
> Issue happened around 2015-11-12 10:48:35. It happened also 2 weeks ago and a couple of months ago.
> Please assist in finding the cause of this behavior and how we can prevent this in future.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-77) ConcurrentModificationException in deploy-artifact
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/JBASMP-77?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on JBASMP-77:
-----------------------------------
Sounds good. Thank you.
> ConcurrentModificationException in deploy-artifact
> --------------------------------------------------
>
> Key: JBASMP-77
> URL: https://issues.jboss.org/browse/JBASMP-77
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.7.Final
> Reporter: Daniele Gaffuri
> Assignee: Tomas Remes
> Fix For: 7.8.Final
>
>
> In the same situation of JBASMP-57 deploy-artifact throws the following exception:
> {code}
> [ERROR] Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null: ConcurrentModificationException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.7.SCE:deploy-artifact (deploy) on project sideup-integration: Could not execute goal deploy-artifact on null. Reason: null
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal deploy-artifact on null. Reason: null
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:159)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:112)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:341)
> at org.jboss.as.plugin.deployment.DeployArtifact.validate(DeployArtifact.java:84)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> ... 22 more
> {code}
> This is probably due to changes in related commit [37bc2c1], causing both deploy and undeploy validate methods to add the set of dependencies to itself:
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> // Allows provided dependencies to be seen
> dependencies.addAll(project.getDependencyArtifacts());
> {code}
> {code}
> final Set<Artifact> dependencies = project.getDependencyArtifacts();
> dependencies.addAll(this.project.getDependencyArtifacts());
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1189) Parser error doesn't point at the problematic line in case of extra double quote
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1189?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi commented on DROOLS-1189:
-------------------------------------------
I guess that it's difficult from Lexer perspective to point at the problematic line in this case. It might be a feature request to add a human-friendly rule analyzer.
> Parser error doesn't point at the problematic line in case of extra double quote
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1189
> URL: https://issues.jboss.org/browse/DROOLS-1189
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Minor
>
> If you have a rule which wrongly has an extra double quote,
> {noformat}
> rule "rule1"
> when
> then
> System.out.println("1"");
> end
>
> rule "rule2"
> when
> then
> System.out.println("2");
> end
>
> rule "rule3"
> when
> then
> System.out.println("3");
> end
> {noformat}
> Drools raises parser errors like this:
> {noformat}
> [20,0]: [ERR 102] Line 20:0 mismatched input ''
> [20,0]: [ERR 102] Line 20:0 mismatched input '<eof>' in rule "rule1"
> [0,0]: Parser returned a null Package
> {noformat}
> It doesn't point at the problematic line which actually contains the extra double quote. So it's difficult for users to find the root cause (Imagine you have bunch of rules generated by decision table).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months