[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-6892:
----------------------------------
Summary: Access logging for EJBs
Key: WFLY-6892
URL: https://issues.jboss.org/browse/WFLY-6892
Project: WildFly
Issue Type: Feature Request
Components: EJB
Affects Versions: 10.0.0.Final
Reporter: Brad Maxwell
Access logging for EJB requests similar to Web access logging would be very useful.
Possibly something like:
{code}
[date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
[date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
[date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6885:
--------------------------------------
Component/s: (was: Transactions)
Assignee: (was: Tom Jenkinson)
> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6885
> URL: https://issues.jboss.org/browse/WFLY-6885
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Marcel Kolsteren
> Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6885:
----------------------------------------
Reading the description more closely this sounds like a purely EJB issue so I'll change the component and let it auto-assign again.
> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6885
> URL: https://issues.jboss.org/browse/WFLY-6885
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 10.0.0.Final
> Reporter: Marcel Kolsteren
> Assignee: Tom Jenkinson
> Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Sanne Grinovero commented on WFCORE-433:
----------------------------------------
{quote}storing diffs as CLI scripts sounds awesome as long as console can generate them and duplication of changes is removed. e.g. first set listen port to 445 and then change to 443. The first rule is then useless as it will be overridden by the second.{quote}
Good point that would be interesting, but in fairness even _git_ would still keep the full history with all duplication. It might even be convenient for auditing reasons to know that person X changed the port to 445 at some point in time, and then someone else changed it to 443 at a second time. The "commit message" would be a nice to have too, so git seems a good fit even if it was just to store an append-only sequence of CLI scripts.
+1 for {quote}human readable diff-like approach{quote}
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JGRP-2014) FILE_PING destination file name can include File.separator characters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2014?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2014:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1306389|https://bugzilla.redhat.com/show_bug.cgi?id=1306389] from POST to MODIFIED
> FILE_PING destination file name can include File.separator characters
> ---------------------------------------------------------------------
>
> Key: JGRP-2014
> URL: https://issues.jboss.org/browse/JGRP-2014
> Project: JGroups
> Issue Type: Bug
> Reporter: Alan Field
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I was attempting to use FILE_PING as the discovery protocol with Infinispan server and the following configuration:
> {noformat}
> <protocol type="FILE_PING">
> <property name="location">${jgroups.file.dir:/Users/afield/Documents}</property>
> </protocol>
> {noformat}
> However, the following exceptions occur when I try to start the server:
> {noformat}
> 15:34:41,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-11) ISPN000078: Starting JGroups Channel
> 15:34:41,675 ERROR [org.jgroups.protocols.FILE_PING] (MSC service thread 1-11) attempt to write data failed at clustered : clustered.list: java.io.FileNotFoundException: /Users/afield/Documents/clustered/3e5f03c6-c297-474a-cb72-1ca0841f8e5c.afield-osx/clustered.list (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.open(FileOutputStream.java:270) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [rt.jar:1.8.0_72]
> at org.jgroups.protocols.FILE_PING.write(FILE_PING.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:116) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:240) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.down(Discovery.java:380) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:107) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:255) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:360) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.down(JChannel.java:791) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel._connect(JChannel.java:564) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:208) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:199) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_72]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_72]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_72]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_72]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176) [infinispan-commons-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:105) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:102) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.security.Security.doPrivileged(Security.java:76) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:49) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:110) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
> {noformat}
> From looking at the code, FILE_PING creates the {{/Users/afield/Documents/clustered}} directory, but the problem is that the {{local_addr}} for the host is {{afield-osx/clustered}}, so {{destination}} is defined as {{75b5c5b8-014d-26ff-c400-5398a96ad3f4.afield-osx/clustered.list}} when {{addressToFilename()}} is called and then the subsequent write fails. File.separator need to be removed or replaced in the {{destination}} variable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months