[JBoss JIRA] (WFLY-4325) Relative path error in context parameter on Windows
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4325?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4325:
-----------------------------------
The case with Paths.get(getClass().getResource()) looks more interesting, can you reproduce this? that could be issue with VFS
> Relative path error in context parameter on Windows
> ---------------------------------------------------
>
> Key: WFLY-4325
> URL: https://issues.jboss.org/browse/WFLY-4325
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
>
> Deploying the Eclipse BIRT viewer with a context parameter containing a relative reference as a context parameter on a windows machine
> <param-value>../birtdata/logs</param-value>
> results in
> {quote}
> 2015-02-05 10:07:37,736 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./birt: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./birt: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.RuntimeException: java.nio.file.InvalidPathException: Illegal char <:> at index 2: \C:\Java\WildFly-9.x-testi\standalone\deployments\birt-4.4.0.war\..\birtdata\logs\org.eclipse.datatools.connectivity.oda_2015_02_05_10_07_37.log.lck
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:221)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2: \C:\Java\WildFly-9.x-testi\standalone\deployments\birt-4.4.0.war\..\birtdata\logs\org.eclipse.datatools.connectivity.oda_2015_02_05_10_07_37.log.lck
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
> at java.nio.file.Paths.get(Paths.java:84)
> at java.util.logging.FileHandler.openFiles(FileHandler.java:438)
> at java.util.logging.FileHandler.<init>(FileHandler.java:318)
> at org.eclipse.birt.report.utility.LoggingUtil.initFileLogger(LoggingUtil.java:103)
> at org.eclipse.birt.report.utility.LoggingUtil.configureLoggers(LoggingUtil.java:76)
> at org.eclipse.birt.report.service.ReportEngineService.<init>(ReportEngineService.java:229)
> at org.eclipse.birt.report.service.ReportEngineService.initEngineInstance(ReportEngineService.java:271)
> at org.eclipse.birt.report.service.BirtViewerReportService.<init>(BirtViewerReportService.java:83)
> at org.eclipse.birt.report.listener.ViewerServletContextListener.contextInitialized(ViewerServletContextListener.java:57)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:192)
> ... 7 more
> {quote}
> This used to work on the 8.x-series
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2422) Simplify the remote-outbound connections
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-2422:
----------------------------------------
Start a discussion on wildfly-dev list
http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003674.html
> Simplify the remote-outbound connections
> ----------------------------------------
>
> Key: WFLY-2422
> URL: https://issues.jboss.org/browse/WFLY-2422
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB, Remoting
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: Tomasz Adamski
> Fix For: 9.0.0.Beta1
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4325) Relative path error in context parameter on Windows
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4325?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4325:
-----------------------------------
this looks to me as bug in brit reporting.
this is the offending code http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.birt.runtime/...
> Relative path error in context parameter on Windows
> ---------------------------------------------------
>
> Key: WFLY-4325
> URL: https://issues.jboss.org/browse/WFLY-4325
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Beta1
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
>
> Deploying the Eclipse BIRT viewer with a context parameter containing a relative reference as a context parameter on a windows machine
> <param-value>../birtdata/logs</param-value>
> results in
> {quote}
> 2015-02-05 10:07:37,736 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./birt: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./birt: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.RuntimeException: java.nio.file.InvalidPathException: Illegal char <:> at index 2: \C:\Java\WildFly-9.x-testi\standalone\deployments\birt-4.4.0.war\..\birtdata\logs\org.eclipse.datatools.connectivity.oda_2015_02_05_10_07_37.log.lck
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:221)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2: \C:\Java\WildFly-9.x-testi\standalone\deployments\birt-4.4.0.war\..\birtdata\logs\org.eclipse.datatools.connectivity.oda_2015_02_05_10_07_37.log.lck
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
> at java.nio.file.Paths.get(Paths.java:84)
> at java.util.logging.FileHandler.openFiles(FileHandler.java:438)
> at java.util.logging.FileHandler.<init>(FileHandler.java:318)
> at org.eclipse.birt.report.utility.LoggingUtil.initFileLogger(LoggingUtil.java:103)
> at org.eclipse.birt.report.utility.LoggingUtil.configureLoggers(LoggingUtil.java:76)
> at org.eclipse.birt.report.service.ReportEngineService.<init>(ReportEngineService.java:229)
> at org.eclipse.birt.report.service.ReportEngineService.initEngineInstance(ReportEngineService.java:271)
> at org.eclipse.birt.report.service.BirtViewerReportService.<init>(BirtViewerReportService.java:83)
> at org.eclipse.birt.report.listener.ViewerServletContextListener.contextInitialized(ViewerServletContextListener.java:57)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:192)
> ... 7 more
> {quote}
> This used to work on the 8.x-series
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-587) Wildfly does not log stack trace of an exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-587?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-587:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198186
> Wildfly does not log stack trace of an exception
> ------------------------------------------------
>
> Key: WFCORE-587
> URL: https://issues.jboss.org/browse/WFCORE-587
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 1.0.0.Alpha19
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> Copied from BZ 1198186:
> AbstractOperationContext.java line 1159 seems to be "swallowing" exceptions. It's possible to get NullPointerException without a stack trace. This makes it impossible to trace the cause of the NPE.
> https://github.com/jbossas/jboss-eap/blob/2292b0a8763683d0fab03efc3de6a29...
> 2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-11) Finding class org.jboss.logging.DelegatingBasicLogger from Module "org.picketbox:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
> 2015-02-27 12:53:26,586 ERROR [|] [org.jboss.as.controller.client] (ServerService Thread Pool -- 29) JBAS014781: Step handler org.jboss.as.controller.AbstractAddStepHandler$1@1e6a7c88 for operation {"operation" => "add","factory-class" => "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory","param" => [("host" => "tp4.app.paypoint.net"),("port" => "6495"),("use-nio" => "true")],"address" => [("subsystem" => "messaging"),("hornetq-server" => "default"),("connector" => "tp4")],"socket-binding" => undefined} at address [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("connector" => "tp4")
> ] failed handling operation rollback -- java.lang.NullPointerException
> 2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-4) Finding class org.jboss.remoting3.UnlockedReadHashMap$EntryIterator from Module "org.jboss.remoting3:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-587) Wildfly does not log stack trace of an exception
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-587?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on WFCORE-587:
-------------------------------------
BZ Issue: https://bugzilla.redhat.com/show_bug.cgi?id=1198186
> Wildfly does not log stack trace of an exception
> ------------------------------------------------
>
> Key: WFCORE-587
> URL: https://issues.jboss.org/browse/WFCORE-587
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 1.0.0.Alpha19
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> Copied from BZ 1198186:
> AbstractOperationContext.java line 1159 seems to be "swallowing" exceptions. It's possible to get NullPointerException without a stack trace. This makes it impossible to trace the cause of the NPE.
> https://github.com/jbossas/jboss-eap/blob/2292b0a8763683d0fab03efc3de6a29...
> 2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-11) Finding class org.jboss.logging.DelegatingBasicLogger from Module "org.picketbox:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
> 2015-02-27 12:53:26,586 ERROR [|] [org.jboss.as.controller.client] (ServerService Thread Pool -- 29) JBAS014781: Step handler org.jboss.as.controller.AbstractAddStepHandler$1@1e6a7c88 for operation {"operation" => "add","factory-class" => "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory","param" => [("host" => "tp4.app.paypoint.net"),("port" => "6495"),("use-nio" => "true")],"address" => [("subsystem" => "messaging"),("hornetq-server" => "default"),("connector" => "tp4")],"socket-binding" => undefined} at address [
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("connector" => "tp4")
> ] failed handling operation rollback -- java.lang.NullPointerException
> 2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-4) Finding class org.jboss.remoting3.UnlockedReadHashMap$EntryIterator from Module "org.jboss.remoting3:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-587) Wildfly does not log stack trace of an exception
by Tomas Hofman (JIRA)
Tomas Hofman created WFCORE-587:
-----------------------------------
Summary: Wildfly does not log stack trace of an exception
Key: WFCORE-587
URL: https://issues.jboss.org/browse/WFCORE-587
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 1.0.0.Alpha19
Reporter: Tomas Hofman
Assignee: Tomas Hofman
Copied from BZ 1198186:
AbstractOperationContext.java line 1159 seems to be "swallowing" exceptions. It's possible to get NullPointerException without a stack trace. This makes it impossible to trace the cause of the NPE.
https://github.com/jbossas/jboss-eap/blob/2292b0a8763683d0fab03efc3de6a29...
2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-11) Finding class org.jboss.logging.DelegatingBasicLogger from Module "org.picketbox:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
2015-02-27 12:53:26,586 ERROR [|] [org.jboss.as.controller.client] (ServerService Thread Pool -- 29) JBAS014781: Step handler org.jboss.as.controller.AbstractAddStepHandler$1@1e6a7c88 for operation {"operation" => "add","factory-class" => "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory","param" => [("host" => "tp4.app.paypoint.net"),("port" => "6495"),("use-nio" => "true")],"address" => [("subsystem" => "messaging"),("hornetq-server" => "default"),("connector" => "tp4")],"socket-binding" => undefined} at address [
("subsystem" => "messaging"),
("hornetq-server" => "default"),
("connector" => "tp4")
] failed handling operation rollback -- java.lang.NullPointerException
2015-02-27 12:53:26,587 TRACE [|] [org.jboss.modules] (MSC service thread 1-4) Finding class org.jboss.remoting3.UnlockedReadHashMap$EntryIterator from Module "org.jboss.remoting3:main" from local module loader @416a8198 (finder: local module finder @376243b5 (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4405) NPE in AstValue.setValue()
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4405?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-4405:
----------------------------------
Do you have a reproducer app that you can share?
> NPE in AstValue.setValue()
> --------------------------
>
> Key: WFLY-4405
> URL: https://issues.jboss.org/browse/WFLY-4405
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.2.0.Final
> Environment: MacOS X, RHEL6
> Reporter: Christer Bernérus
> Assignee: Farah Juma
>
> When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue().
> The code where this happens is in javax.el-3.0.1-b05.jar and looks like this:
> {code:title=AstValue.java|borderStyle=solid}
> /* Note by kchung 10/2013
> * The spec does not say if the value should be cocerced to the target
> * type before setting the value to the target. The conversion is kept
> * here to be backward compatible.
> */
> ctx.setPropertyResolved(false);
> Class<?> targetType = elResolver.getType(ctx, t.base, property);
> if (ctx.isPropertyResolved()) {
> ctx.setPropertyResolved(false);
> Object targetValue = elResolver.convertToType(ctx, value, targetType);
> if (ctx.isPropertyResolved()) {
> value = targetValue;
> } else {
> if (value != null || targetType.isPrimitive()) {
> value = ELSupport.coerceToType(value, targetType);
> }
> }
> }
> {code}
> From my debugging session, I have seen that the code in
> {{elResolver.getType()}} may return null, which happens to me,
> but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE.
> Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBASMP-53) Support --runtime-name for deployment on server groups
by Stanley Hillner (JIRA)
[ https://issues.jboss.org/browse/JBASMP-53?page=com.atlassian.jira.plugin.... ]
Stanley Hillner commented on JBASMP-53:
---------------------------------------
We definitely need this feature since we need to set some dependencies to logical deployment names that omit the version number. In production its no problem since the deployments get their runtime names assigned but for development this is still an issue.
> Support --runtime-name for deployment on server groups
> ------------------------------------------------------
>
> Key: JBASMP-53
> URL: https://issues.jboss.org/browse/JBASMP-53
> Project: JBoss AS Maven Plugins
> Issue Type: Enhancement
> Components: wildfly
> Reporter: James Perkins
> Assignee: James Perkins
>
> The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter).
> It would be nice if the JBoss Maven plugin could add another configuration parameter for this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-329:
------------------------------------------------
Tibor Zimanyi <tzimanyi(a)redhat.com> changed the Status of [bug 1078146|https://bugzilla.redhat.com/show_bug.cgi?id=1078146] from ON_QA to VERIFIED
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.3.0.Beta1
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> 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:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4397) WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
by Wind Wild (JIRA)
[ https://issues.jboss.org/browse/WFLY-4397?page=com.atlassian.jira.plugin.... ]
Wind Wild closed WFLY-4397.
---------------------------
Resolution: Duplicate Issue
Please view the new link:
https://issues.jboss.org/browse/WFLY-4413
thanks!
> WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
> -----------------------------------------------------------------
>
> Key: WFLY-4397
> URL: https://issues.jboss.org/browse/WFLY-4397
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1
> Environment: Java(TM) SE Runtime Environment (build 1.7.0_25)
> Reporter: Wind Wild
> Assignee: Stuart Douglas
>
> Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following:
>
> 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files)
> at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
>
> 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb
> 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string
> 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3)
> 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms
>
> From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following:
> java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol
> java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol
> java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol
> java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol
> java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol
> java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol
> java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol
> java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol
> java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol
> java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol
> java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol
> java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol
> java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED)
>
> So i know there maybe occur connection leak on WildFly, and i made a test as follow:
> I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it.
>
> Moreover, i found a issue is like above problem:
> [WFLY-3652] Network connection leak - JBoss Issue Tracker
>
> but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1.
>
> Who can help me solve this problem? thanks!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months