[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Kabir Khan
User development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/531173#531173
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
1) and 4) have been done.>
> A few points worth remembering:
> a) I have implemented a JavassistParameterizedClassInfo (stolen from the introspection implementation) which handles things like Collection<String>. This basically delegates to the "raw" ClassInfo for Collection, augmented with extra information regarding the <String> bit. These are currently not cached and are created on every access.
>
>
>
>
I have not added caching yet, and adding this simple test passes with the introspection implementation, but fails with the Javassist implementation
public Comparable<String> signatureCachedParameterizedClassInfo()
{
return null;
}
public void testCachedParameterizedClassInfo() throws Throwable
{
Type type = getGenericReturnType("signatureCachedParameterizedClassInfo");
TypeInfo typeInfo1 = getTypeInfoFactory().getTypeInfo(type);
TypeInfo typeInfo2 = getTypeInfoFactory().getTypeInfo(getGenericReturnType("signatureCachedParameterizedClassInfo"));
assertEquals(typeInfo1, typeInfo2);
assertSame(typeInfo1, typeInfo2); // <-- FAILS
//Also check the results of repeated calls to getGenericSuperClass/-Interfaces() etc.
}
Is this object equality a requirement? My fear is that working out the key will be costly
> A few points worth remembering:
> b) JavassistClassInfo should cache the values of isMap() and isCollection()
>
>
>
>
This has been done.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531173#531173
16 years, 3 months
[EJB 3.0] New message: "not seeing default QueuedPessimisticEJBLock behavior"
by cwinfrey
User development,
A new message was posted in the thread "not seeing default QueuedPessimisticEJBLock behavior":
http://community.jboss.org/message/531170#531170
Author : cwinfrey
Profile : http://community.jboss.org/people/cwinfrey
Message:
--------------------------------------------------------------
I posted this to the Transactions thread and the responder indicated that it would be more appropriate in this EJB 3.0 thread.
In the JBoss reading that I have done, the JBoss application server uses a transaction lock to ensure that there is only one active instance of a given entity bean (one with a given primary key) in memory at one time. If any method at all is invoked on an entity bean within a transaction, no other transaction can have access to this bean until the holding transaction commits or is rolled back.
In my testing I am not seeing this behavior. The testing results are consistent with no transaction lock ever being placed. I am hoping that someone can suggest why - and how I can get the default behavior.
Summary of environment:
* JBoss 5.1.0.GA server/default + Oracle datasource
* Oracle 10g
* EJB 3 Entity Beans with CMP
The Entity Beans do not use any custom primary key classes. A Java Long is used for all primary keys. No equals or hashCode method overrides exist. standardjboss.xml has not been modified and no custom container-configurations are implemented. There is no explicit mapping of the entity beans to a container configuration -- JBoss default determination of entity bean to container configuration is used. This should be a container with commit option B and QueuedPessimisticEJBLock.
Summary of test:
Command-line client program accesses a stateless session bean remote interface to execute the test method (executeConcurrencyTest) to update an Entity Bean (Person).
executeConcurrencyTest outline:
* retrieve a Person using EntityManager.find(Person.class, <primary key value>)
* update a field in the record
* (optionally) pause processing for ~1 minute using an ldap retrieval that happens to be very slow
* return from method
Two overlapping test runs, using the same Person primary key, are executed as follows:
* Start Run#1 with the optional pause selected.
* Wait until logging indicates that Run #1 is "pausing".
* Start run#2 without the optional pause.
* Run#2 completes successfully and its update is seen via SQLDeveloper.
* Run#1 completes successfully and its update is seen via SQLDeveloper.
What was expected is that run#2 would block at the EntityManager.find until run#1 transaction completed at the method return, because of a JBoss transaction lock, but this did not happen.
Trace-level logging during test runs does not show any entries for EntityLockInterceptor, which is responsible for scheduling any locks that must be acquired. Of course, this could just mean that no trace-level logging is included in the java code.
EntityLockMonitor service is enabled for jmx-console. Neither listMonitoredBeans nor printLockMonitor show any entries at all during the test runs. AverageContenders, MedianWaitTime, and MaxContenders are always zero.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531170#531170
16 years, 3 months
[JBoss Messaging] New message: "Re: Error configuring DLQ and ExpiryQueue for distributed destination"
by nkeymeulen
User development,
A new message was posted in the thread "Error configuring DLQ and ExpiryQueue for distributed destination":
http://community.jboss.org/message/531158#531158
Author : nkeymeulen
Profile : http://community.jboss.org/people/nkeymeulen
Message:
--------------------------------------------------------------
Hi Steve,
I had a simular problem.
I also created a destination queue like this.
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=*eventTest*"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="Clustered">*false*</attribute>
</mbean>
I wanted to change the *Clustered to true* and than I got the same error message as you :
java.lang.IllegalArgumentException: Queue eventTest is already deployed as clustered = false so cannot redeploy as clustered=true . You must delete the destination first before redeploying
The problem is that the first time a queue destination is created, a record is added to the jbm_postoffice table. (There clustered for my queue was false)
What I did is "delete from jbm_postoffice where queue_name = '*eventTest*'
When I restarted node 1 and node 2 the problem did not occur anymore.
Hope this helps you.
Nathalie
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/531158#531158
16 years, 3 months