[EJB3] - Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1"
To view the discussion, visit: http://community.jboss.org/message/572625#572625
--------------------------------------------------------------
> aravind kopparthi wrote:
>
>
> can you tell me when timeout method gets called by the container in this case process method in singletonBean calls a method on SLSBean's process method. at this time slsbeans instance gets activated by the container and give's that instance to this method call , during this process when a timout gets triggered doesn't it get a reference to another slsb instance to process?
Like I have been saying previously, the second instance of SLSB will only be created if the first instance is in use. So one the 1st timeout on the Singleton bean, you invoke on a SLSB. This results in the creation of the 1st instance of SLSB. *If* the next timeout invocation happens on the singleton bean before the 1st invocation on that SLSB has completed, *only then* will a new instance be created for the SLSB.
As you saw from your logs, the 2nd timeout invocation on the singleton is *not* happening before the 1st invocation finishes. This is due to the fact that you have (by default) configured your singleton bean to be Lock.WRITE type. Change the lock attribute to Lock.READ on that method. That will allow the 2nd timeout on the Singleton to happen while the first invocation on the SLSB is in progress (assuming the SLSB.process is a long running job compared to the timeout interval).
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572625#572625]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months
[JBoss Tools] - Building JBoss Tools Documentaion
by Isaac Rooskov
Isaac Rooskov [http://community.jboss.org/people/irooskov%40redhat.com] modified the document:
"Building JBoss Tools Documentaion"
To view the document, visit: http://community.jboss.org/docs/DOC-13341
--------------------------------------------------------------
You can download a folder with a plug-in either from a Anonymous SVN (http://anonsvn.jboss.org/repos/jbosstools) or a Committer SVN (https://svn.jboss.org/repos/jbosstools) ( if you have commiter rights) repositories . In the plug-in's folder you will find a directory with documentation.This instruction explains how you can build the documentation.
h3. New Prerequisites:
Ensure you have the Maven building tool
Ensure the Nexus repository and profile as defined here: http://community.jboss.org/docs/DOC-15170 http://community.jboss.org/wiki/MavenGettingStarted-Developers are in your *+settings.xml+* file, located in your *%M2_HOME%/conf/* or *%USER_HOME%/.m2/* folder. These settings are required in order to obtain the necessary jDocbook plug-ins that are required to build the JBoss Tools documentation
h3. Previously you would have undertaken:
*+This is no longer necessary+*
2.You need to make sure you have downloaded all required files and folder from the repository:
a) Plug-in folder
b) the +*documentation*+ folder
3.Maven requires a number of plug-ins (jDocBook etc.) to generate JBoss Tools documentation and therefore you need to specify where Maven can download those plug-ins. The easiest way is to create a new profile in the Maven configuration file (*+settings.xml+*). You will find the file in *%M2_HOME%/conf/* or *%USER_HOME%/.m2/*. Open the *+settings.xml+* and add the following profile:
<profile>
<id>documentation</id>
<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
<repository>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<id>repository.jboss.com</id>
<name>Jboss Repository for Maven</name>
<url>http://repository.jboss.com/maven2/</url>
<layout>default</layout>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<id>repository.jboss.com</id>
<name>Jboss Repository for Maven</name>
<url> http://repository.jboss.com/maven2/ </url>
<layout>default</layout>
</pluginRepository>
<pluginRepository>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>snapshots.jboss.org</id>
<name>Jboss Snapshots Repository for Maven</name>
<url>http://snapshots.jboss.org/maven2/</url>
<layout>default</layout>
</pluginRepository>
</pluginRepositories>
</profile>
Then you need to activate the profile if you want to use it permanently. Find the +<activeProfiles>+ tag and add this line as a child element:
<activeProfile>documentation</activeProfile>
Otherwise you should explicitly activate the profile with *-P profile_name* option while building the documentation.
h3.
h3. These steps are still required:
h3. Building Steps
So, you checked out the plug-in for which you want to build documentation and the documentation folder. And now you can proceed to building the documentation.
1.Find the +*pom.xml*+ file, that is responsible for building the documentation, in the plug-in folder you downloaded. Normally it’s located in “/docs/reference”.
2.Run *mvn clean install* or *mvn clean install -P profile_name* (if you didn't activate your profile in Maven's *+settings.xml+*) command in the folder with *+pom.xml+* to start building the documentation.
Example:
user@user-desktop:/home/user/trunk/seam/docs/reference$ mvn clean install
3.If everything is configured correctly you will see a “BUILD SUCCESSFUL” message. You will also see a generated *+target+* folder that contains the built documentation.
Example:
To open the HTML version of the “Seam Dev Tools Reference Guide” guide you need to proceed to
user@user-desktop:/home/user/trunk/seam/docs/seam/docs/reference/target/docbook/publish/en-US/html_single
and open index.html file.
h3. Documentation Profiles
There are 3 profiles that you can build documentation with:
*release* builds release documentation with “new” or “updated” markers next to the corresponding chapters and sections titles
*releaseJBDS* builds release documentation with Jboss.com styles for commercial products
> Remember to redeploy "jbosstools-jdocbook-style" and "jbosstools-docbook-xslt" if it have been changed.
> In order to redeploy you should run 'mvn deploy' from the corresponding directory. You should also have the apropriate credentials to deploy to the http://snapshots.jboss.org/maven2
*diffmk* builds documentation with markers highlighting changes comparing to the previous release version and sets “new” or “updated” markers next to the corresponding chapters and sections titles.*Note:* Please make sure that you have the master_output.xml file (normally the file can be found in \pluginName\docs\reference\en\) as a new guide may not have such file since there's nothing to compare with.
This command launches building documentation with a profile.
mvn install -Pprofile_name
By default, with no profile specified, Night Build docs are generated.
In order to build all the guide from one place you need to have JBoss Tools trunk checked out then cd to JBoss_tools_trunk/documentation/jbds-docs/ to build JBDS guides with jboss.com styles or to JBoss_tools_trunk/documentation/jboss-tools-docs to build JBoss Tools guides.
and run
mvn assembly:assembly
You can optionally use a profile in this command.
mvn assembly:assembly -Pprofile_name
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13341]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 5 months
[JBoss Cache] - Jboss node hangs frequently
by manohar Parelly
manohar Parelly [http://community.jboss.org/people/manohar.parelly] created the discussion
"Jboss node hangs frequently"
To view the discussion, visit: http://community.jboss.org/message/572561#572561
--------------------------------------------------------------
Dear All,
We have a problem in our production environment. One of our 4 jboss nodes is getting hanged frequently.
We have 4 jboss nodes clustered in 2 physical servers. They are running perfectly till 4 months back for almost 2 years.
After starting up 4 nodes one after the other they are running fine till for some period of time (sometimes 10 days, sometimes 2 days).
All of a sudden one of the jboss node is hanging and not receiving any request while other nodes are working fine. If we identify the hanging node immediately and restart the node everything works fine. Otherwise it is impacting other 3 nodes slowly and making them also to hang.
In normal case no.of threads count is not exceeding 200 in any node. But when it hangs, it is showing more than 500 threads in Thread dump.
*Thread dump I have attached. Please check.*
We found below exception in our server.log file just before jboss node goes down. Please check below error:
Please let me know if you need any more information. Please give your suggestions to resolve the issue.
java.lang.RuntimeException: JBossCacheService: exception occurred in cache get after retry ...
at org.jboss.web.tomcat.service.session.JBossCacheWrapper.get(JBossCacheWrapper.java:94)
at org.jboss.web.tomcat.service.session.JBossCacheService.loadSession(JBossCacheService.java:251)
at org.jboss.web.tomcat.service.session.JBossCacheManager.loadSession(JBossCacheManager.java:1010)
at org.jboss.web.tomcat.service.session.JBossCacheManager.findSession(JBossCacheManager.java:782)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2283)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:99)
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:87)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/JSESSION/localhost/atheebweb/MhPmOOs88X4+gQY0qxzIHA**, caller=GlobalTransaction:<172.16.64.21:7811>:678309, lock=write owner=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads] (activeReaders=0, activeWriter=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:500)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:381)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:309)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:183)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5877)
at org.jboss.cache.TreeCache.get(TreeCache.java:3641)
at org.jboss.cache.TreeCache.get(TreeCache.java:3622)
at org.jboss.cache.TreeCache.get(TreeCache.java:3418)
at sun.reflect.GeneratedMethodAccessor143.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy443.get(Unknown Source)
at org.jboss.web.tomcat.service.session.JBossCacheWrapper.get(JBossCacheWrapper.java:78)
... 17 more
Caused by: org.jboss.cache.lock.TimeoutException: read lock for /JSESSION/localhost/atheebweb/MhPmOOs88X4+gQY0qxzIHA** could not be acquired by GlobalTransaction:<172.16.64.21:7811>:678309 after 15000 ms. Locks: Read lock owners: []
Write lock owner: Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads]
, lock info: write owner=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads] (activeReaders=0, activeWriter=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:262)
at org.jboss.cache.Node.acquireReadLock(Node.java:512)
at org.jboss.cache.Node.acquire(Node.java:474)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572561#572561]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months
[EJB3] - Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1"
To view the discussion, visit: http://community.jboss.org/message/572533#572533
--------------------------------------------------------------
> aravind kopparthi wrote:
>
> thanks for the comments. but in my example Singleton is not trying to do any WRITES is it? all the business logic is in SLSBean that this singleton delegates to and that to slsb call that singleton calls is @Asynchronous slbs.process().
The EJB3 container has no way to know what you have in your impl of that method. Unless you explicitly specify as a READ lock, it's by default treated for WRITE lock.
> aravind kopparthi wrote:
>
> my question what is that i need to configure in the interseptors some where where SLSB injected in Singleton are not treaded like regular beans and handle with multiple pool instances when ever a method is invoked by the container ( timeout) or by the calller.
Just mark that timeout method on the singleton to be READ lock type:
import javax.ejb.Lock;
import javax.ejb.LockType;
@Lock(LockType.READ)
@Timeout
public void process(javax.ejb.Timer timer) {
...
If you want READ lock to apply to all business methods in that singleton bean, then specify that annotation on the EJB bean class level.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572533#572533]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months
[EJB3] - Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1"
To view the discussion, visit: http://community.jboss.org/message/572509#572509
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572509#572509]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 5 months