[JBoss JIRA] (JBAOP-355) Improve aopc
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/JBAOP-355?page=com.atlassian.jira.plugin.... ]
Kabir Khan reassigned JBAOP-355:
--------------------------------
Assignee: (was: Kabir Khan)
> Improve aopc
> ------------
>
> Key: JBAOP-355
> URL: https://issues.jboss.org/browse/JBAOP-355
> Project: JBoss AOP
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Kabir Khan
> Fix For: TRUNK
>
>
> Hey Kabir,
> Some hopefully more constructive inputs on aopc:
> 1) It appears that if any jboss-aop.xml is on the classpath defined by the "classpath" element, it gets applied. In the testsuite, I used a broad classpath, and it picks up a file with the same bindings as the file I name in aoppath. This causes aopc to fail; javaassist complains about seeing the same field twice. The workaround is to not specify anything in aoppath. But that's confusing. Seems to me that if aoppath is used, only bindings specified on the files in that path should be applied.
> 2) When trying to figure the above out, I look at the Reference Guide and then get really confused.
> classpath/classpathref -- simple enough.
> src -- isn't really source (i.e. .java) it's class files. It's basically a subset of classpath, right? This isn't spelled out clearly in the docs and the name of the element is confusing.
> aopclasspath -- Huh???
> 3) Also, having "include" as a nested element within src would be more consistent with normal ant usage.
> Cheers,
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1579) NAKACK2 / UNICAST2: last message sent to self may not get delivered
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1579?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1579:
--------------------------------
STABLE would have fixed this for NAKACK2 (not for UNICAST2) when STABLE and STABILITY messages were *not* tagged as NO_RELIABILITY: as STABLE messages were broadcast, they generated new NAKACK2 messages and therefore the undelivered M10 would have been delivered at A when M11 was received.
> NAKACK2 / UNICAST2: last message sent to self may not get delivered
> -------------------------------------------------------------------
>
> Key: JGRP-1579
> URL: https://issues.jboss.org/browse/JGRP-1579
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.2.7, 3.3
>
>
> When A sends a message M that's received by A (M is either a multicast, or a unicast to A), and the message is dropped below NAKACK2 / UNICAST2, then A might *receive* M, but not *deliver* it if M is the last message sent.
> Scenario (for NAKACK2, but similar to UNICAST2):
> - A's table is: HD=9, HR=9
> - A sends M10
> - NAKACK2 adds M10: HD=9, HR=10 (highest-delivered is still 9, as we haven't removed M10 yet)
> - The transport drops M10
> - A sends no further messages
> - STABLE will make sure that A's HR is 10, but since no message was received, we won't *remove* any messages from A's table !
> --> The result is that although A *received* M10, it won't *deliver* M10 (until another message is received) !
> SOLUTION:
> - Maybe we can use the retransmit task to see if there are any unremoved messages in a table and - if so - remove them and pass them up the stack to the application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1579) NAKACK2 / UNICAST2: last message sent to self may not get delivered
by Bela Ban (JIRA)
Bela Ban created JGRP-1579:
------------------------------
Summary: NAKACK2 / UNICAST2: last message sent to self may not get delivered
Key: JGRP-1579
URL: https://issues.jboss.org/browse/JGRP-1579
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.2.7, 3.3
When A sends a message M that's received by A (M is either a multicast, or a unicast to A), and the message is dropped below NAKACK2 / UNICAST2, then A might *receive* M, but not *deliver* it if M is the last message sent.
Scenario (for NAKACK2, but similar to UNICAST2):
- A's table is: HD=9, HR=9
- A sends M10
- NAKACK2 adds M10: HD=9, HR=10 (highest-delivered is still 9, as we haven't removed M10 yet)
- The transport drops M10
- A sends no further messages
- STABLE will make sure that A's HR is 10, but since no message was received, we won't *remove* any messages from A's table !
--> The result is that although A *received* M10, it won't *deliver* M10 (until another message is received) !
SOLUTION:
- Maybe we can use the retransmit task to see if there are any unremoved messages in a table and - if so - remove them and pass them up the stack to the application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (DROOLS-24) forall( p1 p2 p3...) --> not forall
by Marc Dzaebel (JIRA)
Marc Dzaebel created DROOLS-24:
----------------------------------
Summary: forall( p1 p2 p3...) --> not forall
Key: DROOLS-24
URL: https://issues.jboss.org/browse/DROOLS-24
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 5.5
Environment: all
Reporter: Marc Dzaebel
Assignee: Mark Proctor
Priority: Trivial
Expert guide:
"As a side note, forall( p1 p2 p3...) is equivalent to writing:
not(p1 and not(and p2 p3...))"
--> insert not
"As a side note, not forall ..."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBASPECT-39) java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/JBASPECT-39?page=com.atlassian.jira.plugi... ]
Tom Ross updated JBASPECT-39:
-----------------------------
Steps to Reproduce:
Deploy attached EAR file in JBoss EAP 5.1.2 environment with JTS transactions enabled.
Then start the timer by calling the servlet i.e.
http://localhost:8080/testCase/test
Wait about 4 minutes fro the transaction to timeout. The above exception should be visible in the log file.
was:
To reproduce the problem convert a JBoss EAP instance to JTS transactions.
Fire a timer that runs longer than the default transaction timeout. Wait until transaction times out and is rolled back. Then wait until the time finishes. You should see the exception then.
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBASPECT-39
> URL: https://issues.jboss.org/browse/JBASPECT-39
> Project: JBoss Aspects
> Issue Type: Bug
> Environment: JBoss EAP 5.1.2
> Reporter: Tom Ross
> Assignee: Andrew Rubinger
> Attachments: JBASPECT-39_TEST_CASE.ear
>
>
> When a timer runs longer than a transaction timeout it throws an exception:
> {noformat}
> 2013-01-25 15:06:34,613 ERROR [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-144eac73-8911-4bf7-ab78-7ac081374794[target=jboss.j2ee:ear=XX_TEST_CASE.ear,jar=XX_TEST_CASE_EJB.jar,name=TXTimerBean,service=EJB3]) Error invoking ejbTimeout
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >, actual TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >
> at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:157)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:686)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:202)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerBridge.callTimeout(TimedObjectInvokerBridge.java:44)
> at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:664)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBASPECT-39) java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/JBASPECT-39?page=com.atlassian.jira.plugi... ]
Tom Ross updated JBASPECT-39:
-----------------------------
Attachment: JBASPECT-39_TEST_CASE.ear
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple thrown when timer expires in a JTS transaction that has timed out
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBASPECT-39
> URL: https://issues.jboss.org/browse/JBASPECT-39
> Project: JBoss Aspects
> Issue Type: Bug
> Environment: JBoss EAP 5.1.2
> Reporter: Tom Ross
> Assignee: Andrew Rubinger
> Attachments: JBASPECT-39_TEST_CASE.ear
>
>
> When a timer runs longer than a transaction timeout it throws an exception:
> {noformat}
> 2013-01-25 15:06:34,613 ERROR [org.jboss.ejb.txtimer.TimerImpl] (EJB-Timer-144eac73-8911-4bf7-ab78-7ac081374794[target=jboss.j2ee:ear=XX_TEST_CASE.ear,jar=XX_TEST_CASE_EJB.jar,name=TXTimerBean,service=EJB3]) Error invoking ejbTimeout
> java.lang.IllegalStateException: Wrong tx on thread: expected TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >, actual TransactionImple < jts, -3f57fe9c:d04e:51029e16:fc >
> at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:157)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
> at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:686)
> at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:202)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerBridge.callTimeout(TimedObjectInvokerBridge.java:44)
> at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:664)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months