[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7
by John Brush (JIRA)
[ https://issues.jboss.org/browse/JASSIST-195?page=com.atlassian.jira.plugi... ]
John Brush updated JASSIST-195:
-------------------------------
Description:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
{code}
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
{code}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
{code}
Afterwards, it looks like this:
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
{code}
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
BTW: my only workaround for the time being is to force the 1.7 JVM to use the old verifier with -XX:-UseSplitVerifier.
was:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
{code}
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
{code}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
{code}
Afterwards, it looks like this:
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
{code}
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
> Verifier error with try-finally clause in Java 1.7
> ---------------------------------------------------
>
> Key: JASSIST-195
> URL: https://issues.jboss.org/browse/JASSIST-195
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: Oracle Java 1.7 on Mac OS X
> Reporter: John Brush
> Assignee: Shigeru Chiba
>
> After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
> {code}
> public int testInstrumentedCallInFinallyBlock( int i )
> {
> try
> {}
> catch ( Throwable t )
> {}
> finally
> {
> i = incByOne( i );
> }
> return i;
> }
> {code}
> This unit test results in the following exception:
> java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
> After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #3 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: astore_2
> 10: aload_0
> 11: iload_1
> 12: invokespecial #3 // Method incByOne:(I)I
> 15: istore_1
> 16: aload_2
> 17: athrow
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 73 /* same_locals_1_stack_item */
> stack = [ class java/lang/Throwable ]
> frame_type = 8 /* same */
> {code}
> Afterwards, it looks like this:
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #23 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: nop
> 10: nop
> 11: nop
> 12: nop
> 13: nop
> 14: nop
> 15: goto 9
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 249 /* chop */
> offset_delta = 9
> frame_type = 253 /* append */
> offset_delta = 8
> locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
> {code}
> Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
> BTW: my only workaround for the time being is to force the 1.7 JVM to use the old verifier with -XX:-UseSplitVerifier.
--
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, 2 months
[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7
by John Brush (JIRA)
[ https://issues.jboss.org/browse/JASSIST-195?page=com.atlassian.jira.plugi... ]
John Brush updated JASSIST-195:
-------------------------------
Description:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
{code}
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
{code}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
{code}
Afterwards, it looks like this:
{code}
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
{code}
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
was:
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
Afterwards, it looks like this:
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
> Verifier error with try-finally clause in Java 1.7
> ---------------------------------------------------
>
> Key: JASSIST-195
> URL: https://issues.jboss.org/browse/JASSIST-195
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: Oracle Java 1.7 on Mac OS X
> Reporter: John Brush
> Assignee: Shigeru Chiba
>
> After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
> {code}
> public int testInstrumentedCallInFinallyBlock( int i )
> {
> try
> {}
> catch ( Throwable t )
> {}
> finally
> {
> i = incByOne( i );
> }
> return i;
> }
> {code}
> This unit test results in the following exception:
> java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
> After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #3 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: astore_2
> 10: aload_0
> 11: iload_1
> 12: invokespecial #3 // Method incByOne:(I)I
> 15: istore_1
> 16: aload_2
> 17: athrow
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 73 /* same_locals_1_stack_item */
> stack = [ class java/lang/Throwable ]
> frame_type = 8 /* same */
> {code}
> Afterwards, it looks like this:
> {code}
> Code:
> stack=2, locals=3, args_size=2
> 0: aload_0
> 1: iload_1
> 2: invokespecial #23 // Method incByOne:(I)I
> 5: istore_1
> 6: goto 18
> 9: nop
> 10: nop
> 11: nop
> 12: nop
> 13: nop
> 14: nop
> 15: goto 9
> 18: iload_1
> 19: ireturn
> Exception table:
> from to target type
> 9 10 9 any
> StackMapTable: number_of_entries = 2
> frame_type = 249 /* chop */
> offset_delta = 9
> frame_type = 253 /* append */
> offset_delta = 8
> locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
> {code}
> Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
--
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, 2 months
[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7
by John Brush (JIRA)
John Brush created JASSIST-195:
----------------------------------
Summary: Verifier error with try-finally clause in Java 1.7
Key: JASSIST-195
URL: https://issues.jboss.org/browse/JASSIST-195
Project: Javassist
Issue Type: Bug
Affects Versions: 3.17.1-GA
Environment: Oracle Java 1.7 on Mac OS X
Reporter: John Brush
Assignee: Shigeru Chiba
After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance:
public int testInstrumentedCallInFinallyBlock( int i )
{
try
{}
catch ( Throwable t )
{}
finally
{
i = incByOne( i );
}
return i;
}
This unit test results in the following exception:
java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9
After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap():
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #3 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: astore_2
10: aload_0
11: iload_1
12: invokespecial #3 // Method incByOne:(I)I
15: istore_1
16: aload_2
17: athrow
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 73 /* same_locals_1_stack_item */
stack = [ class java/lang/Throwable ]
frame_type = 8 /* same */
Afterwards, it looks like this:
Code:
stack=2, locals=3, args_size=2
0: aload_0
1: iload_1
2: invokespecial #23 // Method incByOne:(I)I
5: istore_1
6: goto 18
9: nop
10: nop
11: nop
12: nop
13: nop
14: nop
15: goto 9
18: iload_1
19: ireturn
Exception table:
from to target type
9 10 9 any
StackMapTable: number_of_entries = 2
frame_type = 249 /* chop */
offset_delta = 9
frame_type = 253 /* append */
offset_delta = 8
locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ]
Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable).
--
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, 2 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Abhi Datt (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Abhi Datt edited comment on AS7-6079 at 4/27/13 2:19 AM:
---------------------------------------------------------
Thanks Fink,
Do you mean to say that in the fixed version the IPT is available?
As when we ported our EJB 2.1 app to JBoss 7.1.1 (from 6.1) we experienced that our database activity has increased 3 times and in the debug mode it was evident that there is no caching available for EJBs. For every method call it hits DB which was not the case earlier. This has resulted in an overall degradation of over 70% of our application in comparison to JBoss AS 6.1.
Do you think this fix covers that issue
Thanks again.
was (Author: abhidatt):
Thanks Fink,
Do you mean to say that in the fixed version the IPT is available?
As when we ported our EJB 2.1 app to JBoss 7.1.1 (from 6.1) we experienced that our database activity has increased 3 times and in the debug mode it was evident that there is no caching available for EJBs. For every method call it hits DB which was not the case earlier. This has resulted in an overall degradation of over 70% of our application in comparison to JBoss AS 6.1.
Do you think this fix covers this issue
Thanks again.
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
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, 2 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Abhi Datt (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Abhi Datt commented on AS7-6079:
--------------------------------
Thanks Fink,
Do you mean to say that in the fixed version the IPT is available?
As when we ported our EJB 2.1 app to JBoss 7.1.1 (from 6.1) we experienced that our database activity has increased 3 times and in the debug mode it was evident that there is no caching available for EJBs. For every method call it hits DB which was not the case earlier. This has resulted in an overall degradation of over 70% of our application in comparison to JBoss AS 6.1.
Do you think this fix covers this issue
Thanks again.
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
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, 2 months
[JBoss JIRA] (JBRULES-3385) Rule not fired depending on the class loading order
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ]
Davide Sottara commented on JBRULES-3385:
-----------------------------------------
It works correctly in 5.5.0+
> Rule not fired depending on the class loading order
> ---------------------------------------------------
>
> Key: JBRULES-3385
> URL: https://issues.jboss.org/browse/JBRULES-3385
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.2.0.Final, 5.3.0.Final
> Environment: SLES11 SP1 with java 1.6.0_14-b08 (32bit and 64bit) or XP with jdk1.6.0_22 (32 or 64 bit)
> Reporter: Manuel Reinaldo Falagan
> Assignee: Mark Proctor
> Priority: Blocker
> Attachments: DROOLS_ERROR.zip, LeftTupleIndexHashTable.java, RightTupleIndexHashTable.java
>
>
> A very simple example "FailTest" triggers a rule only 15 times when it should trigger it 16 times.
> The same example with almost any change to the class model or to the order in loading the classes or the input data or the version of java it works.
> The Class FailTest contains only a main method calling the main method of the Class HelloWorldExample. Running directly the main method in the class HelloWorldExample does work.
> Any change fixes the problem in the example but it moves the error to other part. We have set a test testing more than 2000 million cases of rules/inputs and no matter how we write the rules or the code, we end up finding a case that fails, making the software not usable, as it is not predictable were it is going to fail.
> The case has been uner study for more than a year and we have tried AIX, Linux and XP with DROOLS 5.1, 5.2, 5.3 and the trial of Enterprise edition. The example provided has only been tested to fail for DROOLS 5.3.0 final and Enterprise edition for SLES11 SP1 with the SUN virtual machine (not the IBM one) and for XP but there is no combination for which DROOLS work for the 2000 million cases.
> The example provided is a 7kb example self-contained ( attached file DROOLS_ERROR.zip )
--
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, 2 months
[JBoss JIRA] (JBRULES-3612) Prevent a trait from being applied to a given object
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3612?page=com.atlassian.jira.plug... ]
Davide Sottara resolved JBRULES-3612.
-------------------------------------
Fix Version/s: FUTURE
Resolution: Out of Date
Obsolete. Will be managed in 6.x using strong negation and TMS
> Prevent a trait from being applied to a given object
> ----------------------------------------------------
>
> Key: JBRULES-3612
> URL: https://issues.jboss.org/browse/JBRULES-3612
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Optional
> Fix For: FUTURE
>
>
> For various reasons, a rule may want to prevent the future "don" of a given trait for a given object.
> I propose the use of the "ward" macro, as follows:
> Thing t = ward( $core, BannedTrait.class );
> If another rule, at a later point, will try to apply the BannedTrait or any of its subtypes to $core, that trait will not be applied to $core and (potentially) an exception will be thrown.
> Details:
> $core can be a @Traitable object or a Thing (i.e. an instance of a trait proxy). THe "ward" operation automatically applies the "Thing" trait to $core in case it has not been done yet.
> Optionally, one might use the "grant" macro to undo a ward (suggestions for a better name are encouraged).
> This feature will help in the implementation of "disjunct" or "mutually exclusive" traits, which are incompatible and can't be applied to the same
--
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, 2 months
[JBoss JIRA] (JBRULES-2792) Provide accessability of types and metadata for declare-d types
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2792?page=com.atlassian.jira.plug... ]
Davide Sottara closed JBRULES-2792.
-----------------------------------
Resolution: Done
> Provide accessability of types and metadata for declare-d types
> ---------------------------------------------------------------
>
> Key: JBRULES-2792
> URL: https://issues.jboss.org/browse/JBRULES-2792
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: drools-api
> Affects Versions: 5.1.1.FINAL
> Reporter: Wolfgang Laun
> Assignee: Davide Sottara
> Fix For: 6.0.0.Alpha1
>
>
> * All types created or enhanced by a DRL declare construct must be retrievable from the KnowledgeBase using
> Declare getDeclare( String pkg, String name )
> * A Declare object must provide getters String getPackageName(), getName(), Map<String,Object> getMetaData() (same as Rule)
> * A Declare object must provide Class<?> getFactClass() returning the created or enhanced java-lang.Class.
> * A Declare object must provide long getInferredExpires() returning (for @role(event)) the inferred expiration offset or -1 if none.
--
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, 2 months