[JBoss JIRA] (WFLY-3754) EJB StatefulSessionComponentInstance methodMap includes final Object methods
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3754?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3754:
--------------------------------------
After the stateless interceptors patch this one one instance of this interceptor should be created, so even though it will still waste some memory it will not be per instance, but rather per component.
> EJB StatefulSessionComponentInstance methodMap includes final Object methods
> ----------------------------------------------------------------------------
>
> Key: WFLY-3754
> URL: https://issues.jboss.org/browse/WFLY-3754
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: James Livingston
> Assignee: David Lloyd
>
> StatefulSessionComponentInstance has a methodMap which maintains the ChainedInterceptors for each method. That currently includes final Object methods which are not Business Methods for EJBs (EJB 3.1 4.9.5 "The method must not be declared as final or static"), which results in extra memory overhead for what I believe is the useless interceptors.
> The amount of memory a ChainedInterceptor consumes varies between JVMs, but it is between 280 and 400 bytes in some heap dumps I looked at. With 6 final methods (wait, notify*, getClass) on java.lang.Object that adds approximately 2kb of memory use to each instance of each SFSB.
> This can affect all BasicComponentInstance subclasses, but it is most noticeable for SFSBs due to the larger number of instances.
> The list of methods comes from ComponentConfiguration.getDefinedComponentMethods(), but I'm not sure if filtering the final methods out should be done there or an EJB-specific class since the rule about final methods is from the EJB spec. I'm also not sure if toString, equals and hashCode() should be treated as EJB business methods either.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3648) Improve logging in unhandled websocket exceptions
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3648?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3648.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Improve logging in unhandled websocket exceptions
> -------------------------------------------------
>
> Key: WFLY-3648
> URL: https://issues.jboss.org/browse/WFLY-3648
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web Sockets
> Affects Versions: 8.1.0.Final
> Reporter: John Ament
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> Currently, if an exception is thrown in an @OnMessage method in a websocket server, the exception is not printed anywhere. It would be ideal to catch this exception and report it back to the end user (developer) so that they can be aware of their runtime issues and fix them.
> At least from my experience, these are development problems, and are indicative of something wrong rather than an actual exception.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2837) "UT015005: Error invoking method requestDestroyed on listener class ..." on clean shutdown with session draining
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2837?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2837.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
We now have graceful shutdown support for Undertow, so if a graceful shutdown is initiated then this should no longer be a problem.
> "UT015005: Error invoking method requestDestroyed on listener class ..." on clean shutdown with session draining
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2837
> URL: https://issues.jboss.org/browse/WFLY-2837
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> When using mod_cluster session draining and shutting down, draining for 10 seconds results in problem with invoking requestDestroyed listener event.
> Seems to me like dependency orchestration problem on shutdown..
> {noformat}
> 19:01:31,978 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar) in 437ms
> 19:01:31,978 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT.war) in 462ms
> 19:01:31,981 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 441ms
> 19:01:35,505 INFO [org.jboss.test.clusterbench.web.load.AverageSystemLoadServlet] (default task-2) DONE, I was stressing CPU with 4 evil threads for 5027 milliseconds (including warm-up).
> 19:01:35,510 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: java.lang.RuntimeException: javax.servlet.ServletException: UT010013: Could not instantiate com.sun.faces.config.ConfigureListener
> at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:77) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:297) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:685) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: javax.servlet.ServletException: UT010013: Could not instantiate com.sun.faces.config.ConfigureListener
> at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:50) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:75) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> ... 11 more
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:97)
> at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:41)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1132)
> at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:48) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> ... 12 more
> 19:01:35,513 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.RuntimeException: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.servlet.WeldInitialListener
> at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:77) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:297) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:685) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.servlet.WeldInitialListener
> at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:50) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:75) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> ... 11 more
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:97)
> at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:41)
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1132)
> at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:48) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> ... 12 more
> 19:01:41,578 INFO [org.jboss.modcluster] (MSC service thread 1-6) MODCLUSTER000021: All pending requests drained from default-host:/clusterbench in 10.0 seconds
> 19:01:41,580 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 60) MODCLUSTER000002: Initiating mod_cluster shutdown
> 19:01:41,580 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017521: Undertow AJP listener ajp suspending
> 19:01:41,582 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 19:01:41,583 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017506: Undertow 1.0.0.Beta33 stopping
> 19:01:41,586 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 10026ms
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-1854) web-fragment.xml not loaded from a static module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1854?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-1854:
---------------------------------
Fix Version/s: Awaiting Volunteers
Assignee: (was: Stuart Douglas)
> web-fragment.xml not loaded from a static module
> ------------------------------------------------
>
> Key: WFLY-1854
> URL: https://issues.jboss.org/browse/WFLY-1854
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha3
> Reporter: Marek Schmidt
> Fix For: Awaiting Volunteers
>
> Attachments: WFLY-1854.tar
>
>
> Having a custom static module, e.g. org/jboss/solder which contains solder.jar with META-INF/web-fragment.xml with some filters defined (e.g. CatchExceptionFilter)
> and a WAR application, e.g. catch-basic-servlet (on of Solder examples) with jboss-deployment-structure.xml such as
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="org.jboss.solder" meta-inf="import"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> The filters defined in the solder's web-fragment.xml don't seem to work, while the same app works fine if the solder.jar is deployed in the WAR in the WEB-INF/lib instead of a static module.
> People seem to assume that whatever works for WEB-INF/lib would also work for a static module. This assumption should either be fulfilled or clearly explained to people if it doesn't hold.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (DROOLS-580) Make lifecycle methods for KieSession available on KieContainer
by Antoine Toulme (JIRA)
Antoine Toulme created DROOLS-580:
-------------------------------------
Summary: Make lifecycle methods for KieSession available on KieContainer
Key: DROOLS-580
URL: https://issues.jboss.org/browse/DROOLS-580
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Final
Reporter: Antoine Toulme
Assignee: Mark Proctor
There are a few nice methods on KieContainerImpl that should be exposed on KieContainer, relating to getting existing KieSession objects that are cached in the KieContainer.
We had a short discussion about this on IRC on 8/26.
tmio: hi, I am looking at KieContainerImpl and the method getKieSession(String). It looks like a method I’d like to use in my application to retrieve and reuse consistently a session. Is there a reason why this method is not available on the interface KieContainer? Is it a bad idea to use this method?
[1:56pm] tmio: on top of that this method lazily creates the session - really cool
[1:58pm] tmio: conan: any feedback or advice?
[2:01pm] karstensrage left the chat room. (Ping timeout: 240 seconds)
[2:02pm] psingaram joined the chat room.
[2:07pm] mattd left the chat room. (Ping timeout: 255 seconds)
[2:07pm] karstensrage joined the chat room.
[2:11pm] sbryzak left the chat room. (Ping timeout: 260 seconds)
[2:31pm] conan: tmio I suspect it's not exposed
[2:31pm] conan: as it would then involve having to do caching
[2:31pm] tmio: conan: yes it’s not exposed
[2:32pm] tmio: not sure what you mean by caching? You mean the hashmap there on the KieContainerImpl?:
[2:32pm] tmio: you don’t want this to be exposed?
[2:32pm] conan: actually it looks like all get() does
[2:32pm] conan: is create a new one anyway
[2:32pm] tmio: Would you like me to do the caching myself instead?
[2:32pm] tmio: (doing the caching myself will bring complexity in my app)
[2:32pm] conan: hm no it does cache
[2:32pm] conan: tbh I don't know why we have that there
[2:32pm] conan: etirelli ^
[2:33pm] tmio: ok
[2:33pm] conan: originally we were avoiding keeping references to sessions
[2:33pm] conan: as then you have to deal with life cycles, gc, etc
[2:33pm] tmio: conan: that’s fine, yes indeed
[2:33pm] tmio: I mean, I could keep the session around myself and manage its lifecycle
[2:33pm] tmio: or maybe use CDI
[2:33pm] conan: some how that sneaked in
[2:33pm] conan: not sure why it's used
[2:34pm] Gazzonyx left the chat room. (Ping timeout: 260 seconds)
[2:34pm] tmio: Is it a CDI by product?
[2:34pm] conan: no
[2:35pm] conan: mario did it
[2:35pm] conan: not sure why
[2:35pm] conan: you'll need to ask him tomrrow
[2:35pm] tmio: what’s his nick?
[2:36pm] conan: mfusco
[2:36pm] conan: mf|away right now
[2:37pm] etirelli: reading
[2:38pm] tmio: conan: thx
[2:41pm] hguerrer left the chat room. (Ping timeout: 245 seconds)
[2:47pm] tmio: etirelli: should I wait for Mario or do you know what is happening here?
[2:49pm] etirelli: sorry, mom
[2:54pm] etirelli: tmio: ok, in the beginning we did not had lifecycle management for it, so it was not exposed... looking at the code I believe Mario implemented the lifecycle management
[2:54pm] etirelli: but did not expose the method
[2:55pm] etirelli: tmio: my suggestion: please open a JIRA to request the method be moved to the public API... we can do it for 6.2 in a few weeks... meanwhile, you can downcast to InternalKieBase and use it
[2:57pm] tmio: etirelli: so it’s safe to rely on this?
[2:59pm] etirelli: tmio: yes, when we moved to version 6, we made all methods internal and left just a minimal API as public... we wanted to avoid over polluted public API... unfortunately in the process, we left some methods private that could be public
[2:59pm] tmio: etirelli: ok got it. Will open jira now.
[3:00pm] tmio: etirelli: out of curiosity, will you make this part of KieContainer interface or will you create a new interface for lifecycle?
[3:01pm] etirelli: tmio: KieContainer.. the lifecycle is managed behind the scenes... when you call dispose() on the stateful session, it eventually removes it from the cache
[3:01pm] psingaram left the chat room. (Quit: Leaving)
[3:02pm] tmio: etirelli: last one - do you want this as bug or feature request?
[3:02pm] etirelli: feature request or task
[3:04pm] etirelli: tmio: BTW, be aware that there can only be one named session per container... if you call newKieSession() it overrides the previous one...
[3:04pm] tmio: etirelli: I found that out quickly
[3:04pm] tmio: etirelli: but then I was unable to retrieve the current one instead of getting a new one, so I started looking in the code
[3:04pm] tmio: there was definitely something going on
[3:04pm] psiroky left the chat room. (Quit: Leaving.)
[3:05pm] etirelli: conan: this is something that actually is problematic... but not sure we can fix... if the user calls newKieSession() without disposing the previous one, it will leak...
[3:05pm] etirelli: but not much we can do
[3:06pm] etirelli: the user has to call dispose() when he is done with a stateful session
[3:06pm] tmio: etirelli: if you start by providing methods to retrieve current sessions, we can start doing the right things.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3756:
--------------------------------------
This is not transparent to users, as the adaptor contains API classes that users can use directly, e.g. ServerSetup and ManagementClient
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFCORE-71) ProtocolLogger is used outside org.jboss.as.protocol module but isn't available
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-71?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-71:
-----------------------------------
Fix Version/s: 1.0.0.Alpha6
> ProtocolLogger is used outside org.jboss.as.protocol module but isn't available
> -------------------------------------------------------------------------------
>
> Key: WFCORE-71
> URL: https://issues.jboss.org/browse/WFCORE-71
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha6
>
>
> The ProtocolLogger class is used in a few places in host-controller and server, but the module.xml for the org.jboss.as.protocol module specifically excludes it from being exported.
> The uses aren't complex enough to justify exporting the class, so I'll just change them.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months