date:20070730

[jira] Assigned: (GERONIMO-2286) app client plan still uses Strings for dependency Module IDs

2007-07-30 Thread David Jencks (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks reassigned GERONIMO-2286:
--

Assignee: David Jencks

> app client plan still uses Strings for dependency Module IDs
> 
>
> Key: GERONIMO-2286
> URL: https://issues.apache.org/jira/browse/GERONIMO-2286
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: application client, deployment
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: David Jencks
> Fix For: 1.x, 2.0
>
>
> The geronimo-application-client schema has:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> That would typically be used like this:
>   
> tranql/tranql-connector/1.2/rar
>
> Everywhere else we've changed elements holding module IDs to be of 
> patternType, using separate groupId, artifactId, version, and type elements.  
> There's no reason external-rar should still be a single slash-delimited 
> String here (though internal-rar should be since it's presumably a path 
> within the JAR?).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3362) Enable Tomcat context level cluster

2007-07-30 Thread YunFeng Ma (JIRA)

Enable Tomcat context level cluster
---

 Key: GERONIMO-3362
 URL: https://issues.apache.org/jira/browse/GERONIMO-3362
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Clustering
Affects Versions: 2.0.x, 2.1
Reporter: YunFeng Ma
 Fix For: 2.0.x


Geronimo v1.x supports tomcat context level cluster, but Geronimo v2.0.x only 
support tomcat host level cluster. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3362) Enable Tomcat context level cluster

2007-07-30 Thread YunFeng Ma (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YunFeng Ma updated GERONIMO-3362:
-

Attachment: GERONIMO-3362.patch

> Enable Tomcat context level cluster
> ---
>
> Key: GERONIMO-3362
> URL: https://issues.apache.org/jira/browse/GERONIMO-3362
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Clustering
>Affects Versions: 2.0.x, 2.1
>Reporter: YunFeng Ma
> Fix For: 2.0.x
>
> Attachments: GERONIMO-3362.patch
>
>
> Geronimo v1.x supports tomcat context level cluster, but Geronimo v2.0.x only 
> support tomcat host level cluster. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (GERONIMO-3326) ClassLoader memory leak caused by OpenJPA

2007-07-30 Thread Donald Woods

Kevan, is there an associated OpenJPA JIRA for this, so we can track its
progress?

-Donald

Kevan Miller (JIRA) wrote:

[
https://issues.apache.org/jira/browse/GERONIMO-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kevan Miller updated GERONIMO-3326:
---

Attachment: OpenJPAMemLeak-G.patch
OpenJPAMemLeak-OJPA.patch

I'm attaching patches for both OpenJPA and Geronimo that fixes the problem.

Will need to work with the OpenJPA community to get the OpenJPA patch applied.

With this patch basic deploy/undeploy of DayTrader is much better. I've run
over 350 deploy/undeploys. There may be a bit of memory growth. Without
profiling, it's hard to tell. For infrequent operations like deploy/undeploy,
I'd say things look very good...

I've only deployed/undeployed DT. Would be good to try DT operations in between
deploy/undeploy...

ClassLoader memory leak caused by OpenJPA
-

Key: GERONIMO-3326
URL: https://issues.apache.org/jira/browse/GERONIMO-3326
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: persistence

Affects Versions: 2.0-M7
Reporter: Kevan Miller
Assignee: Kevan Miller
Priority: Critical
Fix For: 2.0

Attachments: OpenJPAMemLeak-G.patch, OpenJPAMemLeak-OJPA.patch

As David Jencks mentioned in GERONIMO-3305, there's a ClassLoader memory leak in deploy/undeploy.
Geronimo is running out of PermGen space in some simple deploy/undeploy scenarios involving OpenJPA. The cause of the problem seems to be the _metas table in PCRegistry. _metas is a ConcurrentReferenceHashMap with WEAK reference keys and HARD reference values. The keys are the PersistenceCapable classes. While the values are the metadata for these classes which are maintained by the internal Meta class.

The cause of the ClassLoader memory leak is simple -- if any of the
objects/classes held by the Meta class (e.g. fieldTypes) have also been loaded
by the same ClassLoader used to load the PersistenceCapable class, the
PersistenceCapable class (the weak key) will never be GCed. The value of the
HashMap entry will always maintain a hard reference to the ClassLoader. Since
the ClassLoader will never be GC'ed, the the the pcClass Class object will
never be GC'able...
The problem can be easily recreated using current Geronimo trunk and the
Geronimo Daytrader application.
FYI, here are the GC Roots for one of our ClassLoaders being leaked --
http://people.apache.org/~kevan/PCRegistryLeak.html
I've contacted the OpenJPA dev list. Hopefully, can get this resolved, quickly.

61 matches

Mail list logo