[JBoss JIRA] (JASSIST-189) Bridge methods are proxied instead of desired methods
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-189?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-189.
---------------------------------
> Bridge methods are proxied instead of desired methods
> -----------------------------------------------------
>
> Key: JASSIST-189
> URL: https://issues.jboss.org/browse/JASSIST-189
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: OS X, Java 1.7.0_09
> Reporter: Donnchadh Ó Donnabháin
> Assignee: Shigeru Chiba
> Fix For: 3.18.0-GA
>
>
> The following test intermittently fails:
> {code}
> package org.javassist.test.covariantproxy;
> import java.lang.reflect.Method;
> import javassist.util.proxy.MethodHandler;
> import javassist.util.proxy.ProxyFactory;
> import javassist.util.proxy.ProxyObject;
> import junit.framework.TestCase;
> public class CovariantProxyTest extends TestCase {
>
> public interface TestProxy {
>
> }
>
> public static class TestMethodHandler implements MethodHandler {
>
> boolean invoked = false;
> public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
> invoked = true;
> return proceed.invoke(self, args);
> }
>
> public boolean wasInvoked() {
> return invoked;
> }
> public void reset() {
> invoked = false;
> }
> }
> public static class Issue {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
> }
>
> public static class PublishedIssue extends Issue {
>
> }
> public static abstract class Article {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
>
> public abstract Issue getIssue();
> }
> public static class PublishedArticle extends Article {
>
> private PublishedIssue issue;
>
> @Override
> public PublishedIssue getIssue() {
> return issue;
> }
>
> public void setIssue(PublishedIssue issue) {
> this.issue = issue;
> }
>
> }
>
> public void testThatCallingAMethodWithCovariantReturnTypeCallsProxy() throws Exception {
> Class persistentClass = PublishedArticle.class;
> ProxyFactory factory = new ProxyFactory();
> factory.setUseCache(false);
> factory.setSuperclass(persistentClass);
> factory.setInterfaces(new Class[] {TestProxy.class});
> Class cl = factory.createClass();
> TestProxy proxy = ( TestProxy ) cl.newInstance();
> TestMethodHandler methodHandler = new TestMethodHandler();
> ( ( ProxyObject ) proxy ).setHandler( methodHandler );
>
> ((Article)proxy).getIssue();
> assertTrue(methodHandler.wasInvoked());
>
> methodHandler.reset();
>
> PublishedArticle article = (PublishedArticle) proxy;
>
> article.getIssue();
>
> assertTrue(methodHandler.wasInvoked());
>
> }
>
> }
> {code}
> Were there tests added for JASSIST-24 ? I don't see any associated source.
> This bug causes a problem in hibernate, described in https://hibernate.onjira.com/browse/HHH-7884 .
> This may be related to JASSIST-162 but the circumstances are slightly different.
> The problem occurs intermittently so it appears to depend on the order in which the methods are processed.
--
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, 1 month
[JBoss JIRA] (JASSIST-180) Javassist fails to load class from jar (com.tivoli.pd.jutil.PDPermResource_cs )
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-180?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-180.
---------------------------------
> Javassist fails to load class from jar (com.tivoli.pd.jutil.PDPermResource_cs )
> -------------------------------------------------------------------------------
>
> Key: JASSIST-180
> URL: https://issues.jboss.org/browse/JASSIST-180
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Reporter: ami tabak
> Assignee: Shigeru Chiba
> Priority: Critical
> Fix For: 3.17.0-GA
>
> Attachments: WebsphereBugSample.zip
>
>
> Trying to load class com.tivoli.mts.util.PDPermResource_cs which has only java dependencies. (based on JAD)
> Getting the following error at instantiation.
> 1. Not sure if its related to the 3.17.0 or just 3.17.1 code drops.
> 2. Not sure why its looking to the second class
> com.tivoli.pd.jutil.PDPermResource_cs
> rather than to what I'm trying to load.
> java.lang.InstantiationException: javassist.CtClassType
> at java.lang.Class.newInstance0(Class.java:357)
> at java.lang.Class.newInstance(Class.java:325)
> at com.optier.bug.report.WASTest.wasTestCase(WASTest.java:42)
> at com.optier.bug.report.WASTest.main(WASTest.java:18)
> Exception in thread "main" java.lang.RuntimeException: cannot find com.tivoli.mts.util.PDPermResource_cs: com.tivoli.pd.jutil.PDPermResource_cs found in com/tivoli/mts/util/PDPermResource_cs.class
> at javassist.CtClassType.getClassFile2(CtClassType.java:194)
> at javassist.CtClassType.makeFieldCache(CtClassType.java:848)
> at javassist.CtClassType.getMembers(CtClassType.java:839)
> at javassist.CtClassType.getDeclaredBehaviors(CtClassType.java:987)
> at com.optier.bug.report.WASTest.wasTestCase(WASTest.java:50)
> at com.optier.bug.report.WASTest.main(WASTest.java:18)
--
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, 1 month
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-163.
---------------------------------
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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, 1 month
[JBoss JIRA] (JASSIST-177) javassist.bytecode.BadBytecode on weblogic.jdbc.jts.Driver:
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-177?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-177.
---------------------------------
> javassist.bytecode.BadBytecode on weblogic.jdbc.jts.Driver:
> -----------------------------------------------------------
>
> Key: JASSIST-177
> URL: https://issues.jboss.org/browse/JASSIST-177
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Reporter: ami tabak
> Assignee: Shigeru Chiba
> Priority: Critical
> Fix For: 3.17.1-GA
>
> Attachments: javassist-3-17-GA-weblogicBugSample.zip, weblogicBugSampleWithOracleDriver.zip
>
>
> Once upgraded from 3.13 to 3.17 GA started receiving the following error:
> Might be reappearance of JASSIST-125.
> I tried to run the test with JDK 1.5 / 6/ 7 Same result.
> java version:1.6.0_16
> test: loading class data from pool:weblogic.jdbc.jts.Driver
> (2)javassist.CtMethod@3b9ab065[public connect (Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection;]
> Found method:(Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection;
> Fetching method attribute:
> Exception in thread "main" javassist.CannotCompileException: by javassist.bytecode.BadBytecode: connect (Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection; in weblogic.jdbc.jts.Driver: dead code detected at 664. No stackmap table generated.
> at javassist.CtBehavior.insertBefore(CtBehavior.java:773)
> at javassist.CtBehavior.insertBefore(CtBehavior.java:730)
> at com.optier.bug.report.Test.main(Test.java:76)
> Caused by: javassist.bytecode.BadBytecode: connect (Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection; in weblogic.jdbc.jts.Driver: dead code detected at 664. No stackmap table generated.
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:103)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.CtBehavior.insertBefore(CtBehavior.java:764)
> ... 2 more
> Caused by: javassist.bytecode.BadBytecode: dead code detected at 664. No stackmap table generated.
> at javassist.bytecode.stackmap.MapMaker.fixDeadcode(MapMaker.java:314)
> at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:297)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:151)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:100)
> ... 5 more
--
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, 1 month
[JBoss JIRA] (JASSIST-176) I get a NPE in TypeData
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-176?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-176.
---------------------------------
> I get a NPE in TypeData
> -----------------------
>
> Key: JASSIST-176
> URL: https://issues.jboss.org/browse/JASSIST-176
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Environment: Java 7
> Reporter: John Bainbridge
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: javassist.jar, javassist.nov7.jar
>
>
> This kills my JVM. I'm looking at trying to make simple test case. It appears to be releated to JASSIST-175
> caused by: java.lang.NullPointerException
> at javassist.bytecode.stackmap.TypeData.commonSuperClassEx(TypeData.java:400)
> at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes2(TypeData.java:342)
> at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes(TypeData.java:325)
> at javassist.bytecode.stackmap.TypeData$TypeVar.dfs(TypeData.java:270)
> at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:301)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:151)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:100)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.expr.ExprEditor.doit(ExprEditor.java:113)
> at javassist.CtClassType.instrument(CtClassType.java:1398)
> at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:75)
> at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
> ... 27 more
--
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, 1 month
[JBoss JIRA] (JASSIST-160) Java.lang.VerifyErrors occur in specific cases when using javaassist with Java 1.7
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-160?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-160.
---------------------------------
> Java.lang.VerifyErrors occur in specific cases when using javaassist with Java 1.7
> ----------------------------------------------------------------------------------
>
> Key: JASSIST-160
> URL: https://issues.jboss.org/browse/JASSIST-160
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA
> Environment: jdk1.7.0_03 on Windows XP SP 3
> Reporter: Avner Singerman
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: jatest.zip
>
>
> We found at least two different cases where inserting bytecode using javaassist results in a class that cannot be loaded with Java 1.7.
> java.lang.VerifyError: Inconsistent stackmap frames at branch target
> java.lang.VerifyError: Bad return type in method
> The exact same code injection on the exact same classes works fine with Java 1.6.
> We upgraded to the latest version of javaassist - 3.16.1.GA, but it didn't solve the problem.
> I'm attaching to this bug a self contained example where you can see both type of errors.
> More details in "Steps to Reproduce".
--
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, 1 month
[JBoss JIRA] (JASSIST-179) Diff functionality for java classes and bundles (jars, ears, sars etc)
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-179?page=com.atlassian.jira.plugi... ]
Shigeru Chiba updated JASSIST-179:
----------------------------------
Fix Version/s: (was: 3.18.0-GA)
> Diff functionality for java classes and bundles (jars, ears, sars etc)
> ----------------------------------------------------------------------
>
> Key: JASSIST-179
> URL: https://issues.jboss.org/browse/JASSIST-179
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.17.1-GA, 3.18.0-GA
> Reporter: Sviatoslav Abramenkov
> Assignee: Shigeru Chiba
> Original Estimate: 2 weeks
> Remaining Estimate: 2 weeks
>
> Quite often you see that your Java application works differently being assembled with different configuration or with another set of libraries.
> Sometimes you may not be sure what actually is running at particular deployments of your application.
> For such cases a flexible diff utility that would compare your classes/bundles and show differences is necessary to find out the cause.
--
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, 1 month
[JBoss JIRA] (AS7-3343) Concurrency issues in ReferenceCountingEntityCache
by Jay Kris (JIRA)
[ https://issues.jboss.org/browse/AS7-3343?page=com.atlassian.jira.plugin.s... ]
Jay Kris commented on AS7-3343:
-------------------------------
Stuart, tested this on EAP 6.1 final, and Exception is still there.
Any work arounds ?
> Concurrency issues in ReferenceCountingEntityCache
> --------------------------------------------------
>
> Key: AS7-3343
> URL: https://issues.jboss.org/browse/AS7-3343
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.CR1b
> Reporter: Alexey Makhmutov
> Assignee: Stuart Douglas
> Fix For: 7.1.0.Final
>
> Attachments: cacheProblemTC.zip
>
>
> While running multithreaded workload against AS 7.1Beta/CR1 for application with Entity EJB 2.x we've faced a lot of following errors:
> * Instance for PK [XXX] already registerd.
> * Instance [YYY] not found in cache
> It seems, that these errors are caused by synchronization issues in ReferenceCountingEntityCache:
> * If two threads are trying to access the cache and there is no ready instance for particular PK in the cache, then both threads are trying to get some instance from the pool and put it into the cache -- as result, the second thread can get 'already registered' exception. We were able to compose a minimal test case application which reproduces this kind of problem (see below).
> * There is a gap in time between the call to Associate interceptor (which puts instance in cache - via 'get' method) and Synchronization interceptor (which calls 'reference' method). During this time instance is not referenced, so it seems it can be removed by some other thread which finish its invocation at the same time. Probably this is the root cause of 'not found in cache' error, however it's hard to create a syntetic test case for it.
--
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, 1 month
