-
1. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
jaikiran Nov 23, 2010 12:35 AM (in response to aravindsk)A new instance of SLSB will only be created when the current SLSB instance is in use in some other invocation. Is that how you are testing this?
-
2. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 12:37 AM (in response to jaikiran)thanks for this quick response. in the above process method i implemented a long running logic. just to test if the second timeout event in Startup bean calls second instance of slsb. but it did not.
File tmpdir = new File("/tmp");File tmpfile = new File(tmpdir, "security.rar");InputStream in = new java.io.FileInputStream(tmpfile);BufferedInputStream fin = new BufferedInputStream(in);File ofile = new File(tmpdir, "security.rar_"+new Date().getTime());OutputStream o = new java.io.FileOutputStream(ofile);BufferedOutputStream fout = new BufferedOutputStream(o);int i;do {i = fin.read();if (i != -1)fout.write(i);} while (i != -1);fin.close();fout.close();File tmpdir = new File("/tmp");
File tmpfile = new File(tmpdir, "security.rar");
InputStream in = new java.io.FileInputStream(tmpfile);
BufferedInputStream fin = new BufferedInputStream(in);
File ofile = new File(tmpdir, "security.rar_"+new Date().getTime());
OutputStream o = new java.io.FileOutputStream(ofile);
BufferedOutputStream fout = new BufferedOutputStream(o);
int i;
do {
i = fin.read();
if (i != -1)
fout.write(i);
} while (i != -1);
fin.close();
fout.close();
-
3. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 12:40 AM (in response to aravindsk)do you think @Asynchronous annotaion on process method stopping from creating a new slsb?
-
4. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
jaikiran Nov 23, 2010 12:41 AM (in response to aravindsk)1) Using java.io.* in EJBs isn't recommended.
2) Are you sure the previous invocation on SLSB is still processing when you invoke on it the second time?
-
5. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 12:46 AM (in response to jaikiran)1> i only need a Bean that can process asynchronously when the timeout expires from Singleton Scheduler. is there any other way?
1.1> i am only simulating a long running database call or FTP calls.
2> timeout event that i set in singleton is 1 sec and in the process method i was reading and copying a 200MB file.
-
6. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 12:53 AM (in response to aravindsk)1. I removed @Async annotation on process method in SLSB but still it shows number of instances 1.
i also looked at the total time spent in this method for each execution shows 67719.. is this in milliseconds?
-
7. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 1:10 AM (in response to aravindsk)just curious when jb3-interceptors-aop.xml says maxSize 30 but admin-console shows only 1 for that SLSB?
-
8. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
wolfc Nov 23, 2010 6:17 AM (in response to aravindsk)Please look at my comment on https://jira.jboss.org/browse/EJBTHREE-1703.
-
9. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 9:16 AM (in response to wolfc)I have followed your link and thinking that i should change default configured annotation pool value to something like this in ejb-intersepters-aop.xml for Stateless Bean domain.?
<annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Pool)">
@org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=7, timeout=10000)
</annotation>no error but i still see that each Singleton Ejb bean is referencing it's injected SLSBean as a just bean instance not as a pool instance. calls are still synchronized.
i tried to create a new SingletonBean2 where i injected same SLSBean and started calling methods on SLSBean similler to SingleTonBean and this time two SLSBeans were created and each one associated only to their SingletonBeans.
what i understand from this is SLSBeans that are injected into SingletonBeans ejbs are maintained as just bean instances instead of pool instances.
please let me know if there is anything that i am doing/expecting unusual.
-
10. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 9:29 AM (in response to jaikiran)Jai: 1) Using java.io.* in EJBs isn't recommended.
is this true for Ejb 3.1 as well?( how about Singleton EJB reading file and transforming and then calling SLSBS for persitence is this recommended?)
i was thinking of using SLSB to read file content and tranform into Entities for persirence. what is the recommend if Ejbs can not read files?
-
11. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
wolfc Nov 23, 2010 10:22 AM (in response to aravindsk) -
12. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
jaikiran Nov 23, 2010 10:27 AM (in response to aravindsk)aravind kopparthi wrote:
Jai: 1) Using java.io.* in EJBs isn't recommended.
is this true for Ejb 3.1 as well?( how about Singleton EJB reading file and transforming and then calling SLSBS for persitence is this recommended?)
i was thinking of using SLSB to read file content and tranform into Entities for persirence. what is the recommend if Ejbs can not read files?
It applies for EJB3.1 as well. Check section 21.2.2 "Programming Restrictions" in EJB3.1 spec for the entire set of restrictions.
As for java.io.* restriction, here's a quote from that section.
An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data.
You don't have to do the file reading part in the EJBs. Just let the EJBs persist your entities.
-
13. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
aravindsk Nov 23, 2010 11:03 AM (in response to aravindsk)Not that i am trying to compare two appservers. same two classes(Singleton,SLSBean) ran perfectly asynchronously as expected pooling multiple slsbs calling slsbs' methods from one singletonBean when i deployed it to glassfish 6.9.1. i am sure i can get some answers or resolutions from Jboss. as i am big fan of Jboss.
09:06:01,234 INFO [STDOUT] TIMEOUT METHOD CALLED09:06:13,578 INFO [STDOUT] MetavanteProcess MetavanteProcess09:06:13,593 INFO [STDOUT] TIMEOUT METHOD CALLED09:06:26,062 INFO [STDOUT] MetavanteProcess MetavanteProcess09:06:26,062 INFO [STDOUT] TIMEOUT METHOD CALLED09:06:37,953 INFO [STDOUT] MetavanteProcess MetavanteProcess09:06:37,968 INFO [STDOUT] TIMEOUT METHOD CALLED09:06:50,437 INFO [STDOUT] MetavanteProcess MetavanteProcess09:06:50,437 INFO [STDOUT] TIMEOUT METHOD CALLED09:06:59,968 INFO [STDOUT] MetavanteProcess MetavanteProcess09:06:59,984 INFO [STDOUT] TIMEOUT METHOD CALLED09:07:12,656 INFO [STDOUT] MetavanteProcess MetavanteProcess09:07:12,656 INFO [STDOUT] TIMEOUT METHOD CALLED09:07:26,593 INFO [STDOUT] MetavanteProcess MetavanteProcess09:07:26,609 INFO [STDOUT] TIMEOUT METHOD CALLED09:07:39,125 INFO [STDOUT] MetavanteProcess MetavanteProcess09:07:39,125 INFO [STDOUT] TIMEOUT METHOD CALLEDloginfo: from glfish
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
INFO: TIMEOUT METHOD CALLED
loginfo from jboss: next timeout is not called until first method process completed on slsb first call
09:06:01,234 INFO [STDOUT] TIMEOUT METHOD CALLED
09:06:13,578 INFO [STDOUT] process completed in slsb
09:06:13,593 INFO [STDOUT] TIMEOUT METHOD CALLED
09:06:26,062 INFO [STDOUT] process completed in slsb
09:06:26,062 INFO [STDOUT] TIMEOUT METHOD CALLED
09:06:37,953 INFO [STDOUT] process completed in slsb
09:06:37,968 INFO [STDOUT] TIMEOUT METHOD CALLED
09:06:50,437 INFO [STDOUT] process completed in slsb
09:06:50,437 INFO [STDOUT] TIMEOUT METHOD CALLED
09:06:59,968 INFO [STDOUT] process completed in slsb
-
14. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
jaikiran Nov 23, 2010 11:09 AM (in response to aravindsk)The EJB3.1 spec says (for singleton bean concurrency):
If the concurrency locking attribute is not specified, it is assumed to be Lock(WRITE). The absence of a concurrency attribute specification on the bean class is equivalent to the specification of Lock(WRITE)on the bean class.
Furthermore, the spec says:
If the container invokes a method associated with a Read lock, any number of other concurrent invocations on Read methods are allowed to access the bean instance simultaneously.
If the container invokes a method associated with a Write lock, no other concurrent invocations will be allowed to proceed until the initial Write method’s processing completes. A concurrent access attempt that is not allowed to proceed due to locking is blocked until it can make forward progress.
Your @Singleton bean doesn't specify any explicit @Lock. So it's treated by default as WRITE lock and that explains the behaviour you are seeing.