JMX and weak references

Hi,
We are having a problem where an RMI object is not being garbage collected. A fellow developer has suggested that since the JMX server has a reference to the object it will never be garbage collected. Does anyone know if the JMX server keeps a weak reference to an object or to garbage collect the object you must unload it from the JMX server?

Hi,
We are having a problem where an RMI object is not
ot being garbage collected. A fellow developer has
suggested that since the JMX server has a reference
to the object it will never be garbage collected.
Does anyone know if the JMX server keeps a weak
reference to an object or to garbage collect the
object you must unload it from the JMX server?not sure exactly what you are saying; but jmx deals with mbeans only. if your remote object is not an mbean object, it would have nothing to do with jmx. to kill an mbean object, use jms to unload it.

Similar Messages

Clearing weak references with inner classes

I have a class which contains several inner classes. During it's lifetime, this object creates several instances of it's internal objects and uses them only internally.
I also have a single weak reference that links to my object from anywhere external to the program.
While profiling, I discovered a memory leak. After examining the core dump under jhat, it appears that the only objects linking to this object are that weak reference from the external program and several intantiated inner classes that reference my object via their implicit this$0 field.
Is this possible? Does mixing inner classes and weak references stop the garbage collector from reclaiming classes?

Based on the information you provide, I question your assertion that these inner objects are used only internally. The most obvious explanation is that you're leaking them and something else is holding a hard reference to them.

Weak, soft and Phantom references

I have got some confusions about reference types in java. These are:-
1. How we create weak and soft references! Are they predefined classes and we extend them, or they are interfaces and we implement them, or they are the concepts we implement by following any particular pattern.
or the references which are gone out of scope are considered as weak references.
2. can we change the type of reference dynamically! as JVM does it.
for eg:-
While the data objects are actually in use (or they are in scope) they are immune because they are strongly referenced by the display windows, once you move to look at something else (or they go out of scope) they become eligable for removal.
3. There is one set of problem I am facing, could that be resolved by weak or soft references.
"I set variables at session level(if they are needed at more than one page."
"At the last page I remove it from session."
"If for example there are 4 page sequence, and user quits after three steps, then the garbage variables are left in the session."
"if I make them as weak reference(or soft reference) then would it be a solution. or will it increase any potential risk of loosing the variables in between the process."
"or is there any way out for my problem using ref package, or it is used only for special purposes, not for a senario like this."
"or I am bound to use request level instead of session level, in these type of problems(which I am presently doing to solve this problem, but in this case I have to to set same attribute 3 times.)"
please comment.
4. What happens when we create an instance of reference queue.
-->does it give us a reference to the main queue that is used by garbage collector. when destroying objects out of scope.
that is garbage collector removes the reference of from the object and makes it point to queue element.
--> or when object goes out of scope, at that time only the reference is removed from the object and is made to point to queue element.
--> and when we do obj=null; at that time also obj reference is made to point to queue element.
please comment. I am confused about how java handles references.
5. does reference queue takes all the junked references.
if yes!
then for eg. we are using a background thread and doing some work when instance of class A is cleared, and doing some other work when instance of class B is cleared up by garbage collector.
queue.remove will return the junked reference, now how will we be determining which object is junked, instance of class A or class B. As reference of object is junked we can't use instanceOf operator.
please comment.
Thanks.

I find the documentation a bit opaque myself.
You create, say, a Weak reference by creating an object of class WeakReference, or a subclass of same. The object referenced (the referent) is a separate object which you pass in the WeakReference's constructor.
As long as the referent exist then calling get on the WeakReference object will return it. Once you call get and put the resulting reference in an object you have a hard reference and you know that the referent won't disappear until you let go of it.
If the referent has been disposed of then get returns null.
Sometimes you want to do extra cleaning up when a reference is cleared. Then you need to subclass the Reference class you are using to add indentifying information about the object that just disappeared. Obviously this can't be a reference to the object itself, that would be a "Hard" reference and would prevent the object being cleared.
You then create a ReferenceQueue, which is an ordinary object you own. The Reference objects have a reference to this queue. What happens is the the GC, when it clears one of these Reference objects, adds the Reference to the queue it references. You run a background thread which takes these cleared references from the queue and, using the extra information you added when you subclassed them, does whatever cleaning up you need to do. A typical example is that you have a Map, with the Reference objects as values. Each reference is extended to store the key, so that the cleanup will remove cleared references from the map.
No, it's not suitable for session objects, because you can't depend on the object still being arround. You can only rely on session timeout. It's a basic problem with web services that you never really know if the user has gone away and abandoned you.

Are weak references cleared with soft ones?

Suppose a program holds both weak and soft references to an object X. Suppose the virtual machine clears all the soft references at once, making X weakly reachable. Is the virtual machine guaranteed to clear all the weak references next before normal execution resumes?
I ask because I am setting up an automatic interning system for immutable objects of a certain class that will guarantee that at most one object of a given value is reachable by the rest of the program at one time but will allow objects to be garbage collected if necessary. I need to decide what reference object(s) to keep to each interned object. If I keep only a weak reference, objects will be discarded at the whim of the virtual machine; I would prefer to keep them around longer so they don't have to be recreated so many times. If I keep only a soft reference, I am concerned that another part of the program might keep a weak reference. If the answer to my question above is "no", the soft reference could be cleared and the interning system could create a second object with the same value while the first is still accessible via the weak reference. It seems safest to keep both a soft reference and a weak reference and only recreate the object if the weak reference has been cleared.

Softs hang around until memory needs dictate theygo.
In my experience (Apple's 1.4 VM) this appears to be
as soon as GC is run, making them effectively
useless. Maybe VMs have improved.Not in my experience (Sun 1.4 VM). Soft references hang around forever. I had to stuff my class with bloat to make the instance larger, then change the VM heap size to get it to start collecting my soft references. Whereas the weak references are dumped ASAP. Inside scoop has it that finalizers will delay object collection a bit so be careful of that.
Also the only guarantee is that soft is cleared before weak when they refer to the same object. in my experience weak references go quickly. Like at the first GC when they are weak. You can not depend on any timing with respect to when the weak will be cleared. I don't think the spec even guarantees that soft will be enqueued before weak. Im not sure on that point.

Soft/Weak References: rule of thumbs?

After reading <a target="extern" href="http://java.sun.com/developer/technicalArticles/ALT/RefObj/index.html">Reference Objects and Garbage Collection</a> i browsed my code and replaced my listener containers with versions that store WeakReference objects. The main idea is to avoid memory leaks by storing references to objects that are not needed anymore (the listener container is the only strong reference left).
Another rule is to use SoftReferences for caches. But I haven't figured out a good way of implementing it (for caches that fill itself with one single SQL statement).
Are there any other examples where it's good advice to use Soft/Weak References?

For listeners, you have to make sure that the listener object is hard referenced - which is usually the case. After you release the listener object from the main application/object/thread, because it's finished or you don't need it anymore, the listener holder should not hold on to such references to avoid OutOfMemoryExceptions. Of course, the best way is always to unregister a listener, but unfortunately, we're not living in a perfect world. No listener is forced to unregister, they can simple forget to unregister. For this reason, it's better to tell the listener: if you register yourself, you should know that you are just referenced via WeakReferences. If the listener suddenly doesn't get listener events, this is a coding error which can be traced and fixed. But if a listener forgets to unregister itself, the resulting memory bloat is much harder to trace.
SQL table caches are difficult. On one hand you want to cache the data, on the other, you want to free this cache memory (temporarily) for more important memory usage. It's always a trade off between 2 advantages. If performance is not the big issue, but you get OutOfMemoryExceptions, then this is critical for the application to continue working. Better a little slower than not at all ... ;-)

Eclipselink log levels issue with weak references

Hi all,
Is it possible to get null pointer exceptions if the log level in eclipselink is set to FINEST and you are logging a weak reference probably in a IdentityWeakReferenceMap and getting a null pointer exception because the weak ref has been garbage collected ?
-Prashanth.

I am getting Nullpointer exception when I set log level to FINER or FINEST in persistence.xml.
DisRootEntityRef entity which is seen in below log has week reference in erml.
Here is the exception full trace:
EL Warning: 2010-05-31 17:06:52.328--UnitOfWork(19025200)--Thread(Thread[)--java.lang.NullPointerException
at oracle.communications.platform.entity.impl.DisRootEntityRefDAO.getRootEntity(DisRootEntityRefDAO.java:300)
at oracle.communications.platform.entity.impl.DisRootEntityRefDAO.getToString(DisRootEntityRefDAO.java:591)
at oracle.communications.platform.entity.impl.DisRootEntityRefDAO.toString(DisRootEntityRefDAO.java:584)
at java.text.MessageFormat.subformat(MessageFormat.java:1246)
at java.text.MessageFormat.format(MessageFormat.java:836)
at java.text.Format.format(Format.java:140)
at java.text.MessageFormat.format(MessageFormat.java:812)
at org.eclipse.persistence.internal.localization.EclipseLinkLocalization.buildMessage(EclipseLinkLocalization.java:77)
at org.eclipse.persistence.internal.localization.TraceLocalization.buildMessage(TraceLocalization.java:30)
at org.eclipse.persistence.logging.AbstractSessionLog.formatMessage(AbstractSessionLog.java:801)
at org.eclipse.persistence.platform.server.ServerLog.log(ServerLog.java:71)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:2571)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3664)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3636)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3612)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3534)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.logDebugMessage(UnitOfWorkImpl.java:5397)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3874)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3844)
at org.eclipse.persistence.queries.ObjectBuildingQuery.registerIndividualResult(ObjectBuildingQuery.java:362)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:588)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:549)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:489)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:441)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:635)
at org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:838)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:464)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:997)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:670)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:958)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:432)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1021)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2858)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1225)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1207)
at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:85)
at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:75)
at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:161)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:230)
at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
at org.eclipse.persistence.indirection.IndirectList.buildDelegate(IndirectList.java:237)
at org.eclipse.persistence.indirection.IndirectList.getDelegate(IndirectList.java:397)
at org.eclipse.persistence.indirection.IndirectList$1.(IndirectList.java:525)
at org.eclipse.persistence.indirection.IndirectList.listIterator(IndirectList.java:524)
at org.eclipse.persistence.indirection.IndirectList.iterator(IndirectList.java:488)
at oracle.communications.platform.persistence.impl.PomsArrayList.iterator(PomsArrayList.java:598)
at oracle.communications.platform.entity.impl.DisResultGroupDAO.getRootEntities(DisResultGroupDAO.java:765)
at oracle.communications.integrity.scanCartridges.sdk.RootEntityLoaderImpl.(RootEntityLoaderImpl.java:37)
at oracle.communications.integrity.scanCartridges.sdk.BaseDiscrepancyDetectionController.init(BaseDiscrepancyDetectionController.java:71)
at oracle.communications.integrity.scanCartridges.sdk.BaseDiscrepancyDetectionController.invoke(BaseDiscrepancyDetectionController.java:41)
at oracle.communications.integrity.cartridges.ciscoextensioncartridge.detectionplugins.ciscodiscrepancydetectionsample.CiscoDiscrepancyDetectionSampleMessageDrivenBean.onMessage(CiscoDiscrepancyDetectionSampleMessageDrivenBean.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy343.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:466)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:327)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4585)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4271)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3747)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:114)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5096)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
oracle.communications.integrity.cartridges.ciscoextensioncartridge.detectionplugins.ciscodiscrepancydetectionsample.CiscoDiscrepancyDetectionSampleMessageDrivenBean
java.lang.NullPointerException
at oracle.communications.platform.entity.impl.DisRootEntityRefDAO.getRootEntity(DisRootEntityRefDAO.java:300)
at oracle.communications.platform.entity.impl.DisRootEntityRefDAO.getToString(DisRootEntityRefDAO.java:591)
at oracle.communications.platform.entity.impl.DisRootEntityRefDAO.toString(DisRootEntityRefDAO.java:584)
at java.text.MessageFormat.subformat(MessageFormat.java:1246)
at java.text.MessageFormat.format(MessageFormat.java:836)
at java.text.Format.format(Format.java:140)
at java.text.MessageFormat.format(MessageFormat.java:812)
at org.eclipse.persistence.internal.localization.EclipseLinkLocalization.buildMessage(EclipseLinkLocalization.java:77)
at org.eclipse.persistence.internal.localization.TraceLocalization.buildMessage(TraceLocalization.java:30)
at org.eclipse.persistence.logging.AbstractSessionLog.formatMessage(AbstractSessionLog.java:801)
at org.eclipse.persistence.platform.server.ServerLog.log(ServerLog.java:71)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:2571)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3664)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3636)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3612)
at org.eclipse.persistence.internal.sessions.AbstractSession.log(AbstractSession.java:3534)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.logDebugMessage(UnitOfWorkImpl.java:5397)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3874)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3844)
at org.eclipse.persistence.queries.ObjectBuildingQuery.registerIndividualResult(ObjectBuildingQuery.java:362)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:588)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:549)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:489)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:441)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:635)
at org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:838)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:464)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:997)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:670)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:958)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:432)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1021)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2858)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1225)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1207)
at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:85)
at org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:75)
at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:161)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:230)
at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
at org.eclipse.persistence.indirection.IndirectList.buildDelegate(IndirectList.java:237)
at org.eclipse.persistence.indirection.IndirectList.getDelegate(IndirectList.java:397)
at org.eclipse.persistence.indirection.IndirectList$1.(IndirectList.java:525)
at org.eclipse.persistence.indirection.IndirectList.listIterator(IndirectList.java:524)
at org.eclipse.persistence.indirection.IndirectList.iterator(IndirectList.java:488)
at oracle.communications.platform.persistence.impl.PomsArrayList.iterator(PomsArrayList.java:598)
at oracle.communications.platform.entity.impl.DisResultGroupDAO.getRootEntities(DisResultGroupDAO.java:765)
at oracle.communications.integrity.scanCartridges.sdk.RootEntityLoaderImpl.(RootEntityLoaderImpl.java:37)
at oracle.communications.integrity.scanCartridges.sdk.BaseDiscrepancyDetectionController.init(BaseDiscrepancyDetectionController.java:71)
at oracle.communications.integrity.scanCartridges.sdk.BaseDiscrepancyDetectionController.invoke(BaseDiscrepancyDetectionController.java:41)
at oracle.communications.integrity.cartridges.ciscoextensioncartridge.detectionplugins.ciscodiscrepancydetectionsample.CiscoDiscrepancyDetectionSampleMessageDrivenBean.onMessage(CiscoDiscrepancyDetectionSampleMessageDrivenBean.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy343.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:466)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:327)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4585)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:4271)
at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3747)
at weblogic.jms.client.JMSSession.access$000(JMSSession.java:114)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5096)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Cannot create weak reference to 'classobj' object

I am trying to run the python Script in a C# program using Iron Python I am getting this type of Error
cannot create weak reference to 'classobj' object
I am using this code for running the python code
var ironPythonRuntime = Python.CreateRuntime();
try
dynamic loadPython = ironPythonRuntime.UseFile("Program.py");
catch (Exception ex)
Console.WriteLine(ex.Message);

Hi Mahesh,
About IronPython issue, It's third-party product. Please redirect to IronPython forum. The link as below.
https://ironpython.codeplex.com/workitem/list/basic
After search this error,
this thread tells me.
Try to use virtualenv. It is used to separate many instances of python and it's libraries - you can have as many virtual environments as possible: python 2.5 , 2.6 , 2.7, whatever - with any combinations of libraries - so you can have for example five
python 2.6 instances with different sets of libraries configured.
By the way, here is also a blog talking about
Running IronPython Scripts from a C# 4.0 Program
Now I will move your thread to "off-topic" forum. Thanks for your understanding.
Best regards,
Kristin
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Weak References in Listener Lists

I've found a common source of memory leaks is when objects that add themselves to listener lists forget to remove themselves when they are done.
It would be nice to generalize and say that listener lists should contain weak references, but there are probably valid cases where a listener's only valid reference is through the listener list.
It would be nice to extend the listener pattern so that the listener could specify if they should be referenced weakly, for examplemodel.addChangeListener(this, true)where true indicates the reference to the listener should be weak.
In some cases like the Model View Controller pattern, it probably makes sense that whenever a view listens to a model it should be weakly referenced. For example, when you construct a JTable and pass the model as a parameter to the constructor, the JTable should always specify a weak reference when it listens to the model.
I think supporting a feature like this in the listener APIs could help reduce the potential for memory leaks and make code a little more maintainable.

There was another time that I dabbled in this idea.
But it always comes back to objects cleaning up
after themselves. Now if its not your code and you
cant ensure good behavior, then perhaps there is
cause. But I'd keep an assert and report the issue
if I saw it trigger.What would fire the assert? The Listener will never be garbage collected while it is listening to something. I assume that you are talking about when the listener is a Swing Object like a JFrame. I don't really like to use gui components as listeners.
If you have to write a clean up method, it kind of defeats the value of having automatic garbage collection to a degree. I like to be able to let my Objects just fall out of scope or just become unreachable when they are no longer needed without having to actively manage their deallocation.

License for using JMX Remote API Reference Implementation

Is JMX Remote API Reference Implementation open source one?
Can we use JMX Remote API Reference Implementation with commercial products?

Hi,
I am not a lawyer.
If you're referring to the JMX RI binary downloads available from here:
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/download.jsp
then please click on the download button and then review the license agreement.
You will see that this is not the GPL license.
As such these downloads are not "open source".
However the JMX API is also part of the OpenJDK project - and the OpenJDK project
itself is open source. The OpenJDK project has a NetBeans IDE JMX project that will
let you easily work with the JMX sources.
See http://openjdk.java.net/groups/jmx/ for more details.
You can review the OpenJDK license agreement and download the OpenJDK sources
from http://openjdk.java.net/
The OpenDMK Project contains an open source implementation of the JMXMP
connector for the JMX API - which is the optional JMX connector defined in the
JMX Remote API 1.0 specification. The JMXMP connector is not part of the OpenJDK
project, but is open sourced by the OpenDMK project.
You can review the OpenDMK license agreement and download the sources and
binaries of the OpenDMK project from here:
http://opendmk.dev.java.net/
For an exact description of what you can or can't do with any of these various sources
and binaries, please read the license agreements that come with each of them.
I hope this helps,
-- daniel
http://blogs.sun.com/jmxetc

Weak reference for MapListeners?

I create objects which implement MapListener and then I register those objects with a CQC. If at some later time the only reference to that object is from the CQC, I would like that object to be garbage collected and the MapListener obviously unregistered. My understanding is that if I create objects and register them as MapListeners, they'll never be GC'd unless I unregister them. Is that right? For my application I'd like the CQC's reference to my MapListener to be a weak reference. Am I correct about all this? Can anyone suggest a work-around for me?
Thanks,
Andrew

Hi Andrew,
CQC (or any of the named cache implementations for that matter) isn't designed to treat listeners weakly, so there really is no clean way of doing what you are asking that I know of. The only thing I can think of is to wrap the other references to your listener object to incorporate a finalizer that will then turn around and unregister the "weak" listener, upon finalization.
For example:
import com.tangosol.net.NamedCache;
import com.tangosol.util.MapEvent;
import com.tangosol.util.MapListener;
import java.util.Iterator;
import java.util.HashSet;
import java.util.Set;
public class MyListener
        implements MapListener
    * The map listener object to wrap.
    * @param listener the map listener
    public MyListener(MapListener listener)
        m_listenerInternal = listener;
    * Register this listener with the specified cache.
    * @param cache the named cache to register this listener with
    public void registerWeakListener(NamedCache cache)
        cache.addMapListener(getListenerInternal());
        m_setCache.add(cache);
    // ----- MapListener interface ----------------------------------------
    * {@inheritDoc}
    public void entryInserted(MapEvent evt)
        getListenerInternal().entryInserted(evt);
    * {@inheritDoc}
    public void entryUpdated(MapEvent evt)
        getListenerInternal().entryUpdated(evt);
    * {@inheritDoc}
    public void entryDeleted(MapEvent evt)
        getListenerInternal().entryDeleted(evt);
    // ----- internal -----------------------------------------------------
    protected MapListener getListenerInternal()
        return m_listenerInternal;
    private MapListener m_listenerInternal;
    private Object      m_finalizer        = new Object()
        public void finalize()
            MapListener listener = m_listenerInternal;
            for (Iterator iter = m_setCache.iterator(); iter.hasNext(); )
                ((NamedCache) iter.next()).removeMapListener(listener);
    private Set         m_setCache         = new HashSet();
    }

Weak references for variables

Hello,
UseWeakReference exists for addEventListener and for dictionaries. Is there any way to set a variable to be a weak reference? Kind of like WkPtr<> in boost for C++? I'd like to use this for function callbacks, amongst other things. Would hate to have to wrap everything in a dictionary as a hack.
Thanks!

Alex,
Not quite what I was hoping for as an answer, but it's an answer nonetheless.
Thanks!
Mark

When do VI and queue references become invalid?

Hi all,
I have a fairly complicated problem, so please bear with me.
1) I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs"). If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type. (The VI does other things too, but for simplicity only this is important.)
2) The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign". This VI effectively stores the references. The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
3) VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values). The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same. The VI ref can become invalid or not, depending on small changes, but is always reproducible. I assume there must be some similarity between VI and queue refs. After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes." In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ?? So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does). I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid. Anyone still following? This didn't solve the problem though. If I reproduce the same scenario using only one instance of the template VI, it works just fine. Furthermore, the VI and queue references are never closed, to aid analysis of the problem. Can anyone shine some light on what happens when a template VI terminates? Could this be the problem?
Unfortunately I cannot include the code.
Thank you whoever is able to make sense of this.
Christie

Christie wrote:
Hi all,
I have a fairly complicated problem, so please bear with me.
1) I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs"). If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type. (The VI does other things too, but for simplicity only this is important.)
2) The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign". This VI effectively stores the references. The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
3) VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values). The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same. The VI ref can become invalid or not, depending on small changes, but is always reproducible. I assume there must be some similarity between VI and queue refs. After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes." In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ?? So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does). I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid. Anyone still following? This didn't solve the problem though. If I reproduce the same scenario using only one instance of the template VI, it works just fine. Furthermore, the VI and queue references are never closed, to aid analysis of the problem. Can anyone shine some light on what happens when a template VI terminates? Could this be the problem?
Unfortunately I cannot include the code.
Thank you whoever is able to make sense of this.
Christie
All LabVIEW refnums do get deallocated automatically when the top-level VI in whose hierarchy the refnum was created goes idle (stops executing). You will have to make sure that the creation of a refnum is done inside a VI hierarchy that stays running for the entire time you want to use that refnum.
Rolf Kalbermatter
Message Edited by rolfk on 06-27-2007 11:52 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Questions on JMX and management-config

I was wondering if anyone can clarify the usage of management-config.
We've got a setup with managed-nodes=all and allow-remote-management=true (other params defaulted). We've got processes that occasionally ping the cluster (via a single node) to log performance statistics and to look for problems that might require intervention (across all nodes via remote management).
I'm trying to determine if the JMX subsystem is completely isolated from runtime cache performance.
1) Does the setting for the read-only flag impact performance in any way? If set to false, is there any sort of locking or synchronization that takes place when querying cluster nodes?
2) Do calls to JMX (and presumably the Invocation Service) share any resources with a Distributed Cache Service?
3) the Default management-config settings in Tangosol-coherence.xml point to the "Management" service - which is not actually defined elsewhere in the configuration file. Is this actually an implicit link to the Invocation Service?
4) Is there a single "Service Thread"? or does each distinct service have its own service thread?
Thanks in advance,
Dave

The performance impact of management is relatively small. The consumption is based on the information "read" (getAttribute/getAttribute) and the frequency of the poll. Polls of the same data element within 1 second will receive the same result for remote nodes.
The formula to determine the network consumption estimation formula for Coherence 3.3 on a single poll of the information is:
Estimated network bytes per poll =
Number of remote Node MBeans retrieved * 725
+ Number of remote Cache MBeans retrieved * 225
+ Number of remote Storage Manager MBeans Retrieved * 720
+ Number of remote Service MBeans Retrieved * 144
+ Number of remote Point to Point MBeans * (Number of Nodes in Grid -1 * 250)
Given the order N size of the Point-to-Point MBeans, It is not recommended to put that information in a loop for a large cluster.
1) Does the setting for the read-only flag impact performance in any way? If set to false, is there any sort of locking or synchronization that takes place when querying cluster nodes?
EW: The Read-only flag does not impact performance. There is no synchronization on read of the objects. Synchronization on update is on an attribute by attribute basis.
2) Do calls to JMX (and presumably the Invocation Service) share any resources with a Distributed Cache Service?
EW: The JMX calls are processed through the Management (Invocation) Service. This shares system (memory, CPU, network) resources with other services. The management information is not processed out-of-band and under extreme load performance will be impacted.
3) the Default management-config settings in Tangosol-coherence.xml point to the "Management" service - which is not actually defined elsewhere in the configuration file. Is this actually an implicit link to the Invocation Service?
EW: The Management service is a non-configurable Invocation service.
4) Is there a single "Service Thread"? or does each distinct service have its own service thread?
EW : Not exactly sure I understand the question. Each service has its' own "Service" thread and thread pool. However, there are some shared components at the TCMP (network) layer.
Hope this helps,
Everett Williams
Message was edited by:
user631017
Message was edited by:
user631017

I am trying to update to i-tunes 11.3 but when I download I get a message that itunes didn't install properly, and a reference to error 127. Any ideas?

I am trying to update to i-tunes 11.3 but when I download I get a message that itunes didn't install properly, and a reference to error 127. Any ideas?

For general advice see Troubleshooting issues with iTunes for Windows updates.
The steps in the second box are a guide to removing everything related to iTunes and then rebuilding it which is often a good starting point unless the symptoms indicate a more specific approach. Review the other boxes and the list of support documents further down page in case one of them applies.
Your library should be unaffected by these steps but there is backup and recovery advice elsewhere in the user tip.
tt2

IAccessible on Windows 8.1 and uiautomation reference leaks causing crashes in our applications.

We have started crashing on Windows 8.1 and I have traced the problem to uiautomation.dll and combase.dll. The root cause of the problem is reference counting. It appears that on Windows 8.1 uiautomation is using keyboard hooks and other means to constantly
query for interfaces leading to reference leaks on UI objects. We use MFC and have code that has relied on reference couting to to lead to calls to DestroyWindow. However on Windows 8.1, in cases where we expect, and historically have had, the window get destroyed,
we have windows now hanging around due to elevated reference counts. I can set breaks in the MFC oleunk.cpp and monitor the reference count going up in CCmdTarget::ExternalAddRef for say, a command bar (menu) and after constantly clicking the menu, the reference
count just keeps increasing and increasing. I can quite quickly cause the reference count to zoom into the hundreds. We started getting reports of crashes on Windows 8.1 from customers and at first I didn't duplicate the issue. Then my Windows 8.1 box rebooted
on me (that's another issue as it did so on its own even though I said to defer the restart and I lost data thanks to that nasty Win 8 feature) and after updates installed, I could easily duplicate the crash.
The version now installed for uiautomation is "7.2.9600.17415 (winblue_r4.141028-1500)" and "6.3.9600.17415 (winblue_r4.141028-1500)" as seen from the Visual Studio debugger's modules window. I do see some release calls coming from
a function named "AccessibleObjectFromWindowTimeOut" and wonder what the "TimeOut" implies. That is because the easiest way for a user to crash our app on Windows 8.1 is to use GoToMeeting on Windows 8.1 and invite a participant to take
control of the application. I can also crash on Windows 8.1 simply by setting various break points and trace points to print messages as I track what is going on. That is, the crashes appear to be dependent on some sort of race condition and the debugger interferes
with the proper functioning of whatever is occurring inside uiautomation and combase. I have never seen the debugger "interfere" with a process in this way. I can run the same app and perform the same tasks on Windows 7 and these calls that cause
the ref count to constantly increase simply are not made (and combase.dll doesn't get injected into our process on Windows 7). I think Microsoft needs to look into what they are doing on Windows 8 and start releasing interfaces they are leaking when obtaining
the IAccessible interface from windows that implement it.
R.D. Holland

A dump file doesn't show the cause of the crash - an ever increasing reference count. I changed an implementation of OnGetObject (MFC API) and and didn't return the IAccessible interface and the reference count remained the same on Windows 8.1 as it does
on Windows 7. I did that after tracing the ever increasing reference count to calls to get IAccessible coming from those MS DLLs. Eventually I made sure we destroy the window when we think it should be destroyed instead of relying on the MFC reference counting
mechanism. We have testing code that relies on UI automation so just refusing to give out IAccessible isn't an option as I don't know the context of the request.
R.D. Holland

JMX and weak references

Similar Messages

Maybe you are looking for