[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-112:
------------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1149621|https://bugzilla.redhat.com/show_bug.cgi?id=1149621] from MODIFIED to ON_QA
> Long server shut-dow with unresponsive client with opened JNDI Context
> ----------------------------------------------------------------------
>
> Key: WFCORE-112
> URL: https://issues.jboss.org/browse/WFCORE-112
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Miroslav Novak
> Assignee: David Lloyd
> Labels: remoting
> Attachments: JNDIContext.java, testcase.zip
>
>
> Description of problem:
> If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes.
> This scenario takes place, when network connections is lost between JMS clients with JNDI context and server.
> Version-Release number of selected component (if applicable):
> jboss-remoting-3.3.3.Final-redhat-1.jar
> How reproducible:
> always
> Steps to Reproduce:
> 1. Start EAP 6.3.1.CP.CR1 on first machine
> 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java)
> 3. Disconnect network between client and server
> 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c)
> Actual results:
> It takes 15 minutes for server to shutdown.
> Expected results:
> Server should shutdown almost immediately.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBWEB-305) No file name information in detail error when compiling the java file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-305?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-305:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1155638|https://bugzilla.redhat.com/show_bug.cgi?id=1155638] from MODIFIED to ON_QA
> No file name information in detail error when compiling the java file
> ----------------------------------------------------------------------
>
> Key: JBWEB-305
> URL: https://issues.jboss.org/browse/JBWEB-305
> Project: JBoss Web
> Issue Type: Bug
> Affects Versions: JBossWeb-7.4.0.GA, JBossWeb-7.5.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Priority: Minor
>
> JBossWeb does not have a fix to https://issues.apache.org/bugzilla/show_bug.cgi?id=54466. Helpful file name information can be left off of compilation errors, for example:
> {code}
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/helloworld2].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004061: An error occurred at line: 32 in the generated java file
> The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3900:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1149646|https://bugzilla.redhat.com/show_bug.cgi?id=1149646] from MODIFIED to ON_QA
> Unable to inject EJB Context into CDI Interceptor
> -------------------------------------------------
>
> Key: WFLY-3900
> URL: https://issues.jboss.org/browse/WFLY-3900
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
> Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log
>
>
> CDI Interceptor cannot inject EJB session context.
> If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject.
> See attached reproducer with source and log file.
> private @Resource SessionContext sessionContext;
> Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
> at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185)
> ... 127 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-161) JMX monitoring is extremely memory inefficient
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-161:
------------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1154868|https://bugzilla.redhat.com/show_bug.cgi?id=1154868] from MODIFIED to ON_QA
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFCORE-161
> URL: https://issues.jboss.org/browse/WFCORE-161
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Koen Janssens
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha11
>
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months