Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] OCL query fails with an SQL statement already in cache
[CDO] OCL query fails with an SQL statement already in cache [message #1098838] Sat, 31 August 2013 19:37 Go to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1199
Registered: July 2009
Location: Canada
Senior Member

Hi,

Having got past the problem of my OCL query failing because an EClass
is not mapped (I rebased to latest git master today), now I get a new
kind of failure.

My more elaborate query today attempts to narrow the scope of matched
objects to those that are in some resource path prefix. For example,

NamedElement.allInstances()->select(e |
e.name = 'Foo' and

e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/')
)

(I have to cast a NamedElement to EObject because although NamedElement
is an indirect subtype of ecore::EModelElement, Ecore removed EObject
from the supertypes of EModelElement some releases ago)

The exception that I get in the log seems to show that my OCL query
bombed on an IllegalStateException indicating that an SQL prepared
statement is already in the cache. I don't know the DB layer at all ...

cW


-------- 8< --------

!ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
!MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
!STACK 0
java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS
WHERE CDO_ID=
? already in cache
at
org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec

tion.java:172)
at
org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.

java:95)
at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge

tObjectType(ObjectTypeTable.java:99)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy

peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal

MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS

trategy.readObjectType(HorizontalMappingStrategy.java:194)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor

eAccessor.java:205)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore

Accessor.java:222)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion

(DBStoreAccessor.java:270)
at
org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit

ory.java:578)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis

ionByVersion(CDORevisionManagerImpl.java:252)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis

ionByVersion(CDORevisionManagerImpl.java:1)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin

gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl

eRevisions(AbstractMappingStrategy.java:220)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS

trategy.handleRevisions(HorizontalMappingStrategy.java:210)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto

reAccessor.java:1084)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre

ator.java:173)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato

r.java:160)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta

te(CDOExtentCreator.java:318)
at
org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato

r.java:262)
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1098845 is a reply to message #1098838] Sat, 31 August 2013 19:54 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1199
Registered: July 2009
Location: Canada
Senior Member

Actually, the SQL-statement-already-in-cache thing was a red herring.

The problem is that when OCL accesses the 'path' feature of a
CDOResource, eGet with the 'path' EAttribute returns null, whereas
invocation (in the debugger) of the CDOResourceNode::getPath() accessor
method returns the resource's correct path.

So, Ecore reflection to get CDOResourceNode::path doesn't work, but
CDOResourceNode::getPath() does.

cW


On 2013-08-31 19:37:21 +0000, Christian W. Damus said:

> Hi,
>
> Having got past the problem of my OCL query failing because an EClass
> is not mapped (I rebased to latest git master today), now I get a new
> kind of failure.
>
> My more elaborate query today attempts to narrow the scope of matched
> objects to those that are in some resource path prefix. For example,
>
> NamedElement.allInstances()->select(e |
> e.name = 'Foo' and
>
> e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/')
> )
>
> (I have to cast a NamedElement to EObject because although NamedElement
> is an indirect subtype of ecore::EModelElement, Ecore removed EObject
> from the supertypes of EModelElement some releases ago)
>
> The exception that I get in the log seems to show that my OCL query
> bombed on an IllegalStateException indicating that an SQL prepared
> statement is already in the cache. I don't know the DB layer at all ...
>
> cW
>
>
> -------- 8< --------
>
> !ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
> !STACK 0
> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS
> WHERE CDO_ID=
> ? already in cache
> at
> org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
>
> tion.java:172)
> at
> org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
>
> java:95)
> at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
>
> tObjectType(ObjectTypeTable.java:99)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
>
> peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
>
> MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>
> trategy.readObjectType(HorizontalMappingStrategy.java:194)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
>
> eAccessor.java:205)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
>
> Accessor.java:222)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
>
> (DBStoreAccessor.java:270)
> at
> org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
>
> ory.java:578)
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>
> ionByVersion(CDORevisionManagerImpl.java:252)
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>
> ionByVersion(CDORevisionManagerImpl.java:1)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
>
> gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
>
> eRevisions(AbstractMappingStrategy.java:220)
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>
> trategy.handleRevisions(HorizontalMappingStrategy.java:210)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
>
> reAccessor.java:1084)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
>
> ator.java:173)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
>
> r.java:160)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
>
> te(CDOExtentCreator.java:318)
> at
> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
>
> r.java:262)
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1098853 is a reply to message #1098845] Sat, 31 August 2013 20:09 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1199
Registered: July 2009
Location: Canada
Senior Member

The CDOResourceNode::path feature is transient and derived from folder
and name.

Adding the following to CDOResourceNodeImpl fixes the problem. Is
there a better way?

cW

-------- 8< --------


@Override
public Object eGet(int featureID, boolean resolve, boolean coreType)
{
switch (featureID)
{
case EresourcePackage.CDO_RESOURCE_NODE__PATH:
return getPath();
default:
return super.eGet(featureID, resolve, coreType);
}
}

@Override
public void eSet(int featureID, Object newValue)
{
switch (featureID)
{
case EresourcePackage.CDO_RESOURCE_NODE__PATH:
setPath((String)newValue);
break;
default:
super.eSet(featureID, newValue);
break;
}
}


On 2013-08-31 19:54:49 +0000, Christian W. Damus said:

> Actually, the SQL-statement-already-in-cache thing was a red herring.
>
> The problem is that when OCL accesses the 'path' feature of a
> CDOResource, eGet with the 'path' EAttribute returns null, whereas
> invocation (in the debugger) of the CDOResourceNode::getPath() accessor
> method returns the resource's correct path.
>
> So, Ecore reflection to get CDOResourceNode::path doesn't work, but
> CDOResourceNode::getPath() does.
>
> cW
>
>
> On 2013-08-31 19:37:21 +0000, Christian W. Damus said:
>
>> Hi,
>>
>> Having got past the problem of my OCL query failing because an EClass
>> is not mapped (I rebased to latest git master today), now I get a new
>> kind of failure.
>>
>> My more elaborate query today attempts to narrow the scope of matched
>> objects to those that are in some resource path prefix. For example,
>>
>> NamedElement.allInstances()->select(e |
>> e.name = 'Foo' and
>>
>> e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/')
>> )
>>
>> (I have to cast a NamedElement to EObject because although NamedElement
>> is an indirect subtype of ecore::EModelElement, Ecore removed EObject
>> from the supertypes of EModelElement some releases ago)
>>
>> The exception that I get in the log seems to show that my OCL query
>> bombed on an IllegalStateException indicating that an SQL prepared
>> statement is already in the cache. I don't know the DB layer at all ...
>>
>> cW
>>
>>
>> -------- 8< --------
>>
>> !ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
>> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
>> !STACK 0
>> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS
>> WHERE CDO_ID=
>> ? already in cache
>> at
>> org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
>>
>> tion.java:172)
>> at
>> org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
>>
>> java:95)
>> at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
>>
>> tObjectType(ObjectTypeTable.java:99)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
>>
>> peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
>>
>> MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>
>> trategy.readObjectType(HorizontalMappingStrategy.java:194)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
>>
>> eAccessor.java:205)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
>>
>> Accessor.java:222)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
>>
>> (DBStoreAccessor.java:270)
>> at
>> org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
>>
>> ory.java:578)
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>
>> ionByVersion(CDORevisionManagerImpl.java:252)
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>
>> ionByVersion(CDORevisionManagerImpl.java:1)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
>>
>> gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
>>
>> eRevisions(AbstractMappingStrategy.java:220)
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>
>> trategy.handleRevisions(HorizontalMappingStrategy.java:210)
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
>>
>> reAccessor.java:1084)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
>>
>> ator.java:173)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
>>
>> r.java:160)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
>>
>> te(CDOExtentCreator.java:318)
>> at
>> org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
>>
>> r.java:262)
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1099109 is a reply to message #1098853] Sun, 01 September 2013 06:04 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Am 31.08.2013 22:09, schrieb Christian W. Damus:
> The CDOResourceNode::path feature is transient and derived from folder and name.
>
> Adding the following to CDOResourceNodeImpl fixes the problem. Is there a better way?
I don't think so. I wonder why the EMF generator didn't generate these eGet/eSet methods. I've added another pair for
CDOResource::uri.

416298: CDOResourceNodes do not support reflective access to derived path attribute
https://bugs.eclipse.org/bugs/show_bug.cgi?id=416298
https://git.eclipse.org/r/#/c/16022/

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>
> cW
>
> -------- 8< --------
>
>
> @Override
> public Object eGet(int featureID, boolean resolve, boolean coreType)
> {
> switch (featureID)
> {
> case EresourcePackage.CDO_RESOURCE_NODE__PATH:
> return getPath();
> default:
> return super.eGet(featureID, resolve, coreType);
> }
> }
>
> @Override
> public void eSet(int featureID, Object newValue)
> {
> switch (featureID)
> {
> case EresourcePackage.CDO_RESOURCE_NODE__PATH:
> setPath((String)newValue);
> break;
> default:
> super.eSet(featureID, newValue);
> break;
> }
> }
>
>
> On 2013-08-31 19:54:49 +0000, Christian W. Damus said:
>
>> Actually, the SQL-statement-already-in-cache thing was a red herring.
>>
>> The problem is that when OCL accesses the 'path' feature of a CDOResource, eGet with the 'path' EAttribute returns
>> null, whereas invocation (in the debugger) of the CDOResourceNode::getPath() accessor method returns the resource's
>> correct path.
>>
>> So, Ecore reflection to get CDOResourceNode::path doesn't work, but CDOResourceNode::getPath() does.
>>
>> cW
>>
>>
>> On 2013-08-31 19:37:21 +0000, Christian W. Damus said:
>>
>>> Hi,
>>>
>>> Having got past the problem of my OCL query failing because an EClass is not mapped (I rebased to latest git master
>>> today), now I get a new kind of failure.
>>>
>>> My more elaborate query today attempts to narrow the scope of matched objects to those that are in some resource
>>> path prefix. For example,
>>>
>>> NamedElement.allInstances()->select(e |
>>> e.name = 'Foo' and
>>>
>>> e.oclAsType(ecore::EObject).eResource().oclAsType(eresource::CDOResource).path.startsWith('/cdamus/') )
>>>
>>> (I have to cast a NamedElement to EObject because although NamedElement is an indirect subtype of
>>> ecore::EModelElement, Ecore removed EObject from the supertypes of EModelElement some releases ago)
>>>
>>> The exception that I get in the log seems to show that my OCL query bombed on an IllegalStateException indicating
>>> that an SQL prepared statement is already in the cache. I don't know the DB layer at all ...
>>>
>>> cW
>>>
>>>
>>> -------- 8< --------
>>>
>>> !ENTRY org.eclipse.net4j.db 4 0 2013-08-31 15:22:47.251
>>> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
>>> !STACK 0
>>> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=
>>> ? already in cache
>>> at org.eclipse.net4j.internal.db.DBConnection.releasePreparedStatement(DBConnec
>>> tion.java:172)
>>> at org.eclipse.net4j.internal.db.DBPreparedStatement.close(DBPreparedStatement.
>>> java:95)
>>> at org.eclipse.net4j.db.DBUtil.close(DBUtil.java:425)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.ObjectTypeTable.ge
>>> tObjectType(ObjectTypeTable.java:99)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.DelegatingObjectTy
>>> peMapper.getObjectType(DelegatingObjectTypeMapper.java:60)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontal
>>> MappingStrategy.readObjectType(AbstractHorizontalMappingStrategy.java:82)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>> trategy.readObjectType(HorizontalMappingStrategy.java:194)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readObjectType(DBStor
>>> eAccessor.java:205)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getObjectType(DBStore
>>> Accessor.java:222)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readRevisionByVersion
>>> (DBStoreAccessor.java:270)
>>> at org.eclipse.emf.cdo.internal.server.Repository.loadRevisionByVersion(Reposit
>>> ory.java:578)
>>> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>> ionByVersion(CDORevisionManagerImpl.java:252)
>>> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevis
>>> ionByVersion(CDORevisionManagerImpl.java:1)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchin
>>> gClassMapping.handleRevisions(HorizontalBranchingClassMapping.java:867)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.handl
>>> eRevisions(AbstractMappingStrategy.java:220)
>>> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalMappingS
>>> trategy.handleRevisions(HorizontalMappingStrategy.java:210)
>>> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.handleRevisions(DBSto
>>> reAccessor.java:1084)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.handleRevisions(CDOExtentCre
>>> ator.java:173)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator.createExtent(CDOExtentCreato
>>> r.java:160)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.handlePersistentSta
>>> te(CDOExtentCreator.java:318)
>>> at org.eclipse.emf.cdo.server.ocl.CDOExtentCreator$Lazy$1$1.run(CDOExtentCreato
>>> r.java:262)
>
>


Re: [CDO] OCL query fails with an SQL statement already in cache [message #1436877 is a reply to message #1099109] Fri, 03 October 2014 14:50 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Christian and Eike,

Sorry to bring this post on top of the list again...
I'm facing a strange problem with OCL queries for a couple of months now.
I'm using CDO 4.3 shipped with Eclipse Modeling Luna 4.4.0.

I'm basically using the following three queries :

applicationv2::Application.allInstances()->select(a:applicationv2::Application|not a.invokes->intersection(self.defines)->isEmpty())


mm::pictograms::PictogramLink.allInstances()->select(pl:mm::pictograms::PictogramLink|pl.businessObjects->includes(self))


mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))


The first one is ok.

The second and third ones are querying the Graphiti model and fail or not, depending on how they are executed.

Starting from a "cold" CDO server (that is a non-empty repository that I just restarted), these queries fail when executed as first thing.

Whereas they run fine when executed after that Graphiti diagrams stored in CDO have been loaded in my RCP application editor.

I either get the same message a Christian on the server side with query n°2 :

!ENTRY org.eclipse.net4j.db 4 0 2014-10-03 14:42:16.279
!MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
!STACK 0
java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
...


Or the following one, on the client side with query n°3 :

java.lang.RuntimeException: org.eclipse.net4j.util.WrappedException: Problem executing OCL query: mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | d.children.link.businessObjects->includes(self))
...
Caused by: org.eclipse.ocl.SemanticException: Unknown type ([mm, pictograms, Diagram])
	at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:352)
	at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:322)
	at org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:512)
	at org.eclipse.ocl.internal.helper.HelperUtil.parseQuery(HelperUtil.java:159)
	at org.eclipse.ocl.internal.helper.OCLHelperImpl.createQuery(OCLHelperImpl.java:170)
	at org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.createQuery(OCLQueryHandler.java:230)
...


Christian already had a look in another post as well as Ed Willink on the OCL side :

http://www.eclipse.org/forums/index.php/t/760318/

Ed asked me to open the following bug report but I could unfortunetaly not help him much to reproduce the problem :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807

I hope one of you can help because I can not figure out what to do...

Kind regards,

Laurent
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1438188 is a reply to message #1436877] Sun, 05 October 2014 17:23 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6483
Registered: July 2009
Senior Member
Hi

I can imagine two possible things may be contributing.

The domain of allInstances() is undefined. The LazyExtentMap for the
Ecore OCL in use by CDO takes a Resource-based view, but CDO may have a
different derivation. A warm CDO may have moved from one Resource to
another and perhaps the ExtentMap is stale. (The Pivot OCL takes a
ResourceSet-based view.)

Unreasonable messages that EClasses cannot be found are often due to
metamodel schizophrenia; you are using the EClass loaded in one model
while the tooling is using another. A warm CDO may have reloaded one
model leaving something stale. (The Pivot OCL's ProjectMap reuses
already loaded models rather than creating rivals.) If the failure
occurs on a cold CDO you are probably loading one model as http:/... (ie
a Java code generated mdel) and another as platform:/resource/...
If you are really determined you can create a third load for
platform:/plugin/... with even more variants if URI normalisation
malfunctions.

For all of the above, a log of Resource loading and unloading, and a log
of eContainer changes on EClasses named "Diagram" may provide some
insight; instrument eBasicSetContainer.

Regards

Ed Willink


On 03/10/2014 15:50, Laurent Le Moux wrote:
> Hi Christian and Eike,
>
> Sorry to bring this post on top of the list again...
> I'm facing a strange problem with OCL queries for a couple of months now.
> I'm using CDO 4.3 shipped with Eclipse Modeling Luna 4.4.0.
>
> I'm basically using the following three queries :
>
>
> applicationv2::Application.allInstances()->select(a:applicationv2::Application|not
> a.invokes->intersection(self.defines)->isEmpty())
>
>
>
> mm::pictograms::PictogramLink.allInstances()->select(pl:mm::pictograms::PictogramLink|pl.businessObjects->includes(self))
>
>
>
>
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
>
>
> The first one is ok.
>
> The second and third ones are querying the Graphiti model and fail or
> not, depending on how they are executed.
>
> Starting from a "cold" CDO server (that is a non-empty repository that I
> just restarted), these queries fail when executed as first thing.
>
> Whereas they run fine when executed after that Graphiti diagrams stored
> in CDO have been loaded in my RCP application editor.
>
> I either get the same message a Christian on the server side with query
> n°2 :
>
>
> !ENTRY org.eclipse.net4j.db 4 0 2014-10-03 14:42:16.279
> !MESSAGE SELECT CDO_CLASS FROM CDO_OBJECTS WHERE CDO_ID=? already in cache
> !STACK 0
> java.lang.IllegalStateException: SELECT CDO_CLASS FROM CDO_OBJECTS WHERE
> CDO_ID=? already in cache
> ..
>
>
> Or the following one, on the client side with query n°3 :
>
>
> java.lang.RuntimeException: org.eclipse.net4j.util.WrappedException:
> Problem executing OCL query:
> mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram
> | d.children.link.businessObjects->includes(self))
> ..
> Caused by: org.eclipse.ocl.SemanticException: Unknown type ([mm,
> pictograms, Diagram])
> at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:352)
> at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:322)
> at
> org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:512)
>
> at
> org.eclipse.ocl.internal.helper.HelperUtil.parseQuery(HelperUtil.java:159)
> at
> org.eclipse.ocl.internal.helper.OCLHelperImpl.createQuery(OCLHelperImpl.java:170)
>
> at
> org.eclipse.emf.cdo.server.ocl.OCLQueryHandler.createQuery(OCLQueryHandler.java:230)
>
> ..
>
>
> Christian already had a look in another post as well as Ed Willink on
> the OCL side :
>
> http://www.eclipse.org/forums/index.php/t/760318/
>
> Ed asked me to open the following bug report but I could unfortunetaly
> not help him much to reproduce the problem :
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807
>
> I hope one of you can help because I can not figure out what to do...
>
> Kind regards,
>
> Laurent
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1439848 is a reply to message #1438188] Tue, 07 October 2014 15:40 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Ed,

What do you mean by "The domain of allInstances() is undefined" ? What's missing in my query ? Is the "mm::pictograms::Diagram" prefix not enough in mm::pictograms::Diagram.allInstances() ?

Concerning the potential "metamodel schizophrenia", you'll find attached my ecore models as well as the Graphiti one. Does it mean there's something wrong with their Ns URI ?

Concerning the log, I would like to provide you with all necessary details but I don't understand what to do. What do you mean by "instrument eBasicSetContainer" ? I found no eBasicSetContainer method in the EMF generated code or in CDO API...

Kind regards,

Laurent
  • Attachment: model.zip
    (Size: 9.22KB, Downloaded 87 times)
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1439895 is a reply to message #1439848] Tue, 07 October 2014 16:46 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6483
Registered: July 2009
Senior Member
Hi

Answers in line


On 07/10/2014 16:40, Laurent Le Moux wrote:
> Hi Ed,
>
> What do you mean by "The domain of allInstances() is undefined" ?

Not defined in the OCL specification.

> What's missing in my query ? Is the "mm::pictograms::Diagram" prefix not enough in mm::pictograms::Diagram.allInstances() ?
>
> Concerning the potential "metamodel schizophrenia", you'll find attached my ecore models as well as the Graphiti one. Does it mean there's something wrong with their Ns URI ?

Metamodel schizophrenia is nothing to do with the model, it is to do
with allowing the model to be loaded more than once. Hence my
recommendation to instrument resource loading.

Consider an analogy.

Go to your bank and get a 10 dollar note.

Then go and get another one.

They will not be the same; they have different serial numbers.

Rather similar to a model repository; unless you take care, you get
another copy of an EClass which is not the same; it has a different
object identity and and so it fails to satisfy type conformance tests.

Even more brutal, see what the Java result of

new Double(1.0).equals(new Double(1.0)) is.

> Concerning the log, I would like to provide you with all necessary details but I don't understand what to do. What do you mean by "instrument eBasicSetContainer" ? I found no eBasicSetContainer method in the EMF generated code or in CDO API...

BasicEObjectImpl.eBasicSetContainer(InternalEObject newContainer, int
newContainerFeatureID)

Regards

Ed Willink
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1440356 is a reply to message #1439895] Wed, 08 October 2014 09:05 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Ed,

Thank you for the explanations. BasicEObjectImpl is a class I know nothing about. It looks indeed like some kind of probe that could be used for logging...

I looked for information but I only found the API and some basic examples on programcreek.com...

Could you please give me details on how to log resource loading and unloading as well as eContainer changes on the Diagram EClass using BasicEObjectImpl.eBasicSetContainer ?

Regards,

Laurent
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1440551 is a reply to message #1440356] Wed, 08 October 2014 13:59 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6483
Registered: July 2009
Senior Member
Hi

I'm sorry, but if you do not know how to add println's to Eclipse plugin
sources you are not going to be able to solve your problem.

Regards

Ed Willink

On 08/10/2014 10:05, Laurent Le Moux wrote:
> Hi Ed,
>
> Thank you for the explanations. BasicEObjectImpl is a class I know
> nothing about. It looks indeed like some kind of probe that could be
> used for logging...
>
> I looked for information but I only found the API and some basic
> examples on programcreek.com...
>
> Could you please give me details on how to log resource loading and
> unloading as well as eContainer changes on the Diagram EClass using
> BasicEObjectImpl.eBasicSetContainer ?
>
> Regards,
>
> Laurent
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1444776 is a reply to message #1440551] Tue, 14 October 2014 14:37 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

Println is widely documented. Whereas I found only the API and 3 basic examples on how to use BasicEObjectImpl :

http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/emf/ecore/impl/BasicEObjectImpl.html

http://www.programcreek.com/java-api-examples/index.php?api=org.eclipse.emf.ecore.impl.BasicEObjectImpl

From these examples and the protected constructor, my first guess was that objects like a CDOResource could be cast as BasicEObjectImpl.

But, eBasicSetContainer() seems to be based on a notification mechanism (thus something more elaborated than a println...).
By the way, the source code indicates that eBasicSetContainer(InternalEObject newContainer, int newContainerFeatureID) throws an UnsupportedOperationException...

https://eclipse.googlesource.com/emf/org.eclipse.emf/+/a1ba85bc37a6dfa3cc9d9ea2e06af978a3acc929/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/impl/BasicEObjectImpl.java

That's the reason why, I am (kindly) asking for a little bit more information than just a method name... Wink

For now, as I'm not able to use BasicEObjectImpl, I tried to get more details about my problem.

The query fails on a cold server but is normally executed once a Graphiti diagram has been open in my application editor (i.e. has been loaded from CDO).

I found another topic with a similar problem. But it remained unanswered :

http://www.eclipse.org/forums/index.php/t/627850/

Basically, the idea seems to be that packages useful for OCL are not available in the CDO package registry.

Hereafter is a log of the package registry for a cold server :

Key : http://user/1.0, Package : user.impl.UserPackageImpl@244bb9 (name: user) (nsURI: http://user/1.0, nsPrefix: user)
Key : http://eclipse.org/graphiti/mm, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm, parentURI=null]
Key : http://eclipse.org/graphiti/mm/algorithms/styles, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm/algorithms/styles, parentURI=http://eclipse.org/graphiti/mm/algorithms]
Key : http://lemoux.fr/modeling/framework/commons/metadata/commit, Package : CDOPackageInfo[packageURI=http://lemoux.fr/modeling/framework/commons/metadata/commit, parentURI=null]
Key : http://service/2.0, Package : servicev2.impl.Servicev2PackageImpl@1ca6954 (name: servicev2) (nsURI: http://service/2.0, nsPrefix: servicev2)
Key : http://www.eclipse.org/emf/CDO/security/4.1.0, Package : org.eclipse.emf.cdo.security.impl.SecurityPackageImpl@127fa03 (name: security) (nsURI: http://www.eclipse.org/emf/CDO/security/4.1.0, nsPrefix: security)
Key : http://repositorystructure/2.0, Package : repositorystructurev2.impl.Repositorystructurev2PackageImpl@62b39f (name: repositorystructurev2) (nsURI: http://repositorystructure/2.0, nsPrefix: repositorystructurev2)
Key : http://eclipse.org/graphiti/mm/algorithms, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm/algorithms, parentURI=http://eclipse.org/graphiti/mm]
Key : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, Package : org.eclipse.emf.cdo.eresource.impl.EresourcePackageImpl@145d424 (name: eresource) (nsURI: http://www.eclipse.org/emf/CDO/Eresource/4.0.0, nsPrefix: eresource)
Key : http://lemoux.fr/modeling/framework/commons/metadata/configuration, Package : metadata.configuration.impl.ConfigurationPackageImpl@b72ce1 (name: configuration) (nsURI: http://lemoux.fr/modeling/framework/commons/metadata/configuration, nsPrefix: co)
Key : http://www.eclipse.org/emf/2002/Ecore, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/2002/Ecore, parentURI=null]
Key : http://www.eclipse.org/emf/CDO/expressions/4.3.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/expressions/4.3.0, parentURI=null]
Key : http://application/2.0, Package : applicationv2.impl.Applicationv2PackageImpl@7e9bed (name: applicationv2) (nsURI: http://application/2.0, nsPrefix: applicationv2)
Key : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/Etypes/4.0.0, parentURI=null]
Key : http://eclipse.org/graphiti/mm/pictograms, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm/pictograms, parentURI=http://eclipse.org/graphiti/mm]


And for one from which a diagram has been loaded and my OCL query succefully executed :

Key : http://user/1.0, Package : user.impl.UserPackageImpl@244bb9 (name: user) (nsURI: http://user/1.0, nsPrefix: user)
Key : http://eclipse.org/graphiti/mm, Package : CDOPackageInfo[packageURI=http://eclipse.org/graphiti/mm, parentURI=null]
Key : http://eclipse.org/graphiti/mm/algorithms/styles, Package : org.eclipse.graphiti.mm.algorithms.styles.impl.StylesPackageImpl@1737e47 (name: styles) (nsURI: http://eclipse.org/graphiti/mm/algorithms/styles, nsPrefix: st)
Key : http://lemoux.fr/modeling/framework/commons/metadata/commit, Package : metadata.commit.impl.CommitPackageImpl@1a4071a (name: commit) (nsURI: http://lemoux.fr/modeling/framework/commons/metadata/commit, nsPrefix: cm)
Key : http://service/2.0, Package : servicev2.impl.Servicev2PackageImpl@1ca6954 (name: servicev2) (nsURI: http://service/2.0, nsPrefix: servicev2)
Key : http://www.eclipse.org/emf/CDO/security/4.1.0, Package : org.eclipse.emf.cdo.security.impl.SecurityPackageImpl@127fa03 (name: security) (nsURI: http://www.eclipse.org/emf/CDO/security/4.1.0, nsPrefix: security)
Key : http://repositorystructure/2.0, Package : repositorystructurev2.impl.Repositorystructurev2PackageImpl@62b39f (name: repositorystructurev2) (nsURI: http://repositorystructure/2.0, nsPrefix: repositorystructurev2)
Key : http://eclipse.org/graphiti/mm/algorithms, Package : org.eclipse.graphiti.mm.algorithms.impl.AlgorithmsPackageImpl@8d116e (name: algorithms) (nsURI: http://eclipse.org/graphiti/mm/algorithms, nsPrefix: al)
Key : http://www.eclipse.org/emf/CDO/Eresource/4.0.0, Package : org.eclipse.emf.cdo.eresource.impl.EresourcePackageImpl@145d424 (name: eresource) (nsURI: http://www.eclipse.org/emf/CDO/Eresource/4.0.0, nsPrefix: eresource)
Key : http://lemoux.fr/modeling/framework/commons/metadata/configuration, Package : metadata.configuration.impl.ConfigurationPackageImpl@b72ce1 (name: configuration) (nsURI: http://lemoux.fr/modeling/framework/commons/metadata/configuration, nsPrefix: co)
Key : http://www.eclipse.org/emf/2002/Ecore, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/2002/Ecore, parentURI=null]
Key : http://www.eclipse.org/emf/CDO/expressions/4.3.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/expressions/4.3.0, parentURI=null]
Key : http://application/2.0, Package : applicationv2.impl.Applicationv2PackageImpl@7e9bed (name: applicationv2) (nsURI: http://application/2.0, nsPrefix: applicationv2)
Key : http://www.eclipse.org/emf/CDO/Etypes/4.0.0, Package : CDOPackageInfo[packageURI=http://www.eclipse.org/emf/CDO/Etypes/4.0.0, parentURI=null]
Key : http://eclipse.org/graphiti/mm/pictograms, Package : org.eclipse.graphiti.mm.pictograms.impl.PictogramsPackageImpl@1d62a85 (name: pictograms) (nsURI: http://eclipse.org/graphiti/mm/pictograms, nsPrefix: pi)


I tried to "force" package registration as follow, but it makes no change :

CDOPackageRegistry packageRegistry = transaction.getSession().getPackageRegistry();
Iterator<Entry<String, Object>> it = packageRegistry.entrySet().iterator();
while (it.hasNext()) {
	Entry<String, Object> item = it.next();
	if ((item.getValue() instanceof MmPackage) || (item.getValue() instanceof AlgorithmsPackage)
			|| (item.getValue() instanceof PictogramsPackage))
		it.remove();
}
packageRegistry.putEPackage(MmPackage.eINSTANCE);
packageRegistry.putEPackage(AlgorithmsPackage.eINSTANCE);
packageRegistry.putEPackage(PictogramsPackage.eINSTANCE);

// Look for all diagrams where the element appears
String diagramsQuery = "mm::pictograms::Diagram.allInstances()->select(d:mm::pictograms::Diagram | "
	+ "d.children.link.businessObjects->includes(self))";

CDOQuery cqDiagrams = transaction.createQuery("ocl", diagramsQuery, element.cdoID(), true);
final List<Diagram> diagrams = cqDiagrams.getResult(Diagram.class);


The OCL query is still failing on a cold server.. Sad

Hope someone can help...

Regards,

Laurent
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1444786 is a reply to message #1444776] Tue, 14 October 2014 14:54 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
One more information if it helps...

Loading a Graphiti diagram from CDO into my editor is done the following way :
From an element in the repository selected by the user in a navigator tree, I get its containing CDO resource. From there, I look for the diagram in the resource and I open the editor providing an editor input with the diagram URI.

Whereas, the OCL query is executed on the selected element. And I try to get the diagram(s) back without navigating through my repository elements and their resource.
So, there's no explicit resource loading in the second case...
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1445353 is a reply to message #1444786] Wed, 15 October 2014 10:19 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

I finally found a solution based on other CDO / OCL users answers in the topics mentioned above.

I imported the 'org.eclipse.ecore.ocl' plugin as source project to modify EcoreEnvironment.findPackage as follow and deployed again my CDO server with this modified plugin :

...
for (Object next : registry.values()) {
	EPackage ePackage = null;
	if (next instanceof CDOPackageInfo)
		ePackage = ((CDOPackageInfo) next).getEPackage();
	if (next instanceof EPackage)
		ePackage = (EPackage) next;

	if (ePackage != null) {
		// only consider root-level packages when searching by name
		if ((ePackage.getESuperPackage() == null)
			&& EcoreForeignMethods.isNamed(name, ePackage)) {
					
				EPackage tentativeResult = findNestedPackage(
						packageNames.subList(1, packageNames.size()),
						ePackage);
					
				if (tentativeResult != null) {
					return tentativeResult;
				}
		}
	}
}
...


I also had to disable performance tuning on my CDO client side as explained in the bug 339948 :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=339948

My OCL queries are now working fine on a cold CDO server.
But I introduced a dependency on 'org.eclipse.emf.cdo.common' in 'org.eclipse.ecore.ocl'.

I push this information to the opened bug 435807 :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807

Kind regards,

Laurent
Re: [CDO] OCL query fails with an SQL statement already in cache [message #1446102 is a reply to message #1445353] Thu, 16 October 2014 11:07 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6483
Registered: July 2009
Senior Member
Hi

Well solved.

Please use Bugzilla as the primary communication channel for bugs.

Discussion continues on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807.

Regards

Ed Willink


On 15/10/2014 11:19, Laurent Le Moux wrote:
> Hi again,
>
> I finally found a solution based on other CDO / OCL users answers in the
> topics mentioned above.
>
> I imported the 'org.eclipse.ecore.ocl' plugin as source project to
> modify EcoreEnvironment.findPackage as follow and deployed again my CDO
> server with this modified plugin :
>
>
> ..
> for (Object next : registry.values()) {
> EPackage ePackage = null;
> if (next instanceof CDOPackageInfo)
> ePackage = ((CDOPackageInfo) next).getEPackage();
> if (next instanceof EPackage)
> ePackage = (EPackage) next;
>
> if (ePackage != null) {
> // only consider root-level packages when searching by name
> if ((ePackage.getESuperPackage() == null)
> && EcoreForeignMethods.isNamed(name, ePackage)) {
>
> EPackage tentativeResult = findNestedPackage(
> packageNames.subList(1, packageNames.size()),
> ePackage);
>
> if (tentativeResult != null) {
> return tentativeResult;
> }
> }
> }
> }
> ..
>
>
> I also had to disable performance tuning on my CDO client side as
> explained in the bug 339948 :
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=339948
>
> My OCL queries are now working fine on a cold CDO server.
> But I introduced a dependency on 'org.eclipse.emf.cdo.common' in
> 'org.eclipse.ecore.ocl'.
>
> I push this information to the opened bug 435807 :
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=435807
>
> Kind regards,
>
> Laurent
Previous Topic:Final modifier in EMF-generated methods
Next Topic:Transient preprocessing modifications on model before a subsequent transformation
Goto Forum:
  


Current Time: Wed Oct 23 18:24:23 GMT 2019

Powered by FUDForum. Page generated in 0.02762 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top