[Security & JAAS/JBoss] - SecurityAssociation.threadSubjectStacks leaks when TimerServ
by alexeinov
Subject stack grows infinitely in SecurityAssociation when timer is called. Memory allocated to stack is never freed, which is a memory leak that after a while leads to OutOfMemory condition.
I tried to run the following code in JBoss 4.2.3 GA as well as in Branch_4_2. I can see that the objects count of the class org.jboss.security.SecurityAssociation$SubjectContext grows by two with each timer call. This is the code:
| package mbean;
|
| import org.jboss.annotation.ejb.Management;
|
| @Management
| public interface TimerAuthMBean {
|
| void start() throws Exception;
|
| }
|
| import javax.annotation.Resource;
| import javax.ejb.Timeout;
| import javax.ejb.Timer;
| import javax.ejb.TimerService;
|
| import org.apache.commons.logging.Log;
| import org.apache.commons.logging.LogFactory;
| import org.jboss.annotation.ejb.Service;
|
| @Service(name = "TimerAuthenticationTest")
| public class TimerAuthMBeanImpl implements TimerAuthMBean {
|
| private Log log = LogFactory.getLog(this.getClass());
|
| @Resource
| private TimerService timerService;
|
| public void start() {
| timerService.createTimer(10000, 3000, "FooTimer");
| }
|
| @Timeout
| public void onTime(final Timer timer) {
| log.debug("Timer called");
| }
|
| }
|
Further profiling have shown that calls to push() and pop() methods are not balanced when the above code is running. There are two extra push() calls that are never backed with pop() calls. Here are push() and pop() methods in SecurityAssociations$SubjectThreadLocalStack:
| private static class SubjectThreadLocalStack
| {
| ...
| void push(SubjectContext context)
| {
| ArrayList stack = (ArrayList) local.get();
| stack.add(context);
| }
| ...
| SubjectContext pop()
| {
| ArrayList stack = (ArrayList) local.get();
| SubjectContext context = null;
| int lastIndex = stack.size() - 1;
| if (lastIndex >= 0)
| context = (SubjectContext) stack.remove(lastIndex);
| return context;
| }
| }
|
These two extra push() calls are initiated from the callTimeout() method in org.jboss.ejb3.service.ServiceContainer class. This method calls SecurityAssociation.setPrincipal(), which pushes the subject thread, and does nothing to set it back. Looks strange to me.
Is this a bug or am I missing some part of configuration? Are there workarounds?
I could not think about something better than to pop the subjects stack forcefully from my timer code like this:
| SecurityAssociation.popSubjectContext();
| SecurityAssociation.popSubjectContext();
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249081#4249081
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249081
16 years, 8 months
[Clustering/JBoss] - clustering w/ JBoss Pojo Cache and JTA without using AS
by ttruong
Hi,
I have posted this also under JBoss Pojo Cache (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=159741) but that might be a better place:
Ee are evaluating JBoss Pojo Cache and JTA/HA-JNDI for clustering and global transactions to use within our server (agent) implementations. Our agents holds a data container. The goal here is to cluster our agents on different nodes and JVMs in a cluster by having an agent's data container replicated in each cluster's node.
The requirements for the cluster are:
- fail over solution: currently client requests uses RMI to access the agent. In case of a graceful/disgraceful leave of an agent node the client requests should be handled by another node within the cluster
- (at the beginning simple) load balancing: read operations should be handled by one agent node and write operations by another agent node.
Since this would be a major change for our architecture we do not want to use an application server in the first place. Instead we want to keep our agents to run stand alone and being cluster and JTA enabled.
The questions are:
- is there anybody experiencing with clustering using JBoss Cache and JTA without deploying it in an AS?
- it seems that for global transactions and fail over HA-JNDI is a requirement for JTA. As far as we could see HA-JNDI is tightly coupled to JBoss AS and cannot be used stand-alone. Correct?
- Is there a HA-JNDI standalone solution?
- Is there another stand-alone alternative for HA-JNDI?
- Is there a stand-alone load balancer available for doing both: load balancing and re-routing request in case a node crashes?
Thanks in advance
Tai
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249076#4249076
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249076
16 years, 8 months
[JBoss jBPM] - From "decision" to "join" possible?
by unsavory
Is it possible to go directly from a decision to a join within an execution?
Example:
<fork name="agreement complete">
| <transition to="send registration email" />
| <transition to="check if language exam required" />
| </fork>
|
| <java name="send registration email" expr="#{ mailService }" method="sendVendorOnboardingEmail">
| <arg><object expr="#{ user }" /></arg>
| <arg><string value="application/application_received.ftl" /></arg>
| <transition to="screening join" />
| </java>
|
| <decision name="check if language exam required">
| <transition to="complete zh language exam">
| <condition expr="#{ user.jobApplication.language == 'zh' }" />
| </transition>
| <!-- <transition to="screening join">
| <condition expr="#{ user.jobApplication.language != 'zh' }" />
| </transition> -->
| <transition to="screening join" />
| </decision>
|
| <task name="complete zh language exam" assignee="#{ user.stringId }">
| <transition name="complete" to="screening join" />
| </task>
|
| <join name="screening join">
| <transition to="screen applicant" />
| </join>
When I execute my process, it seems that the decision never passes through to the join. The join is still in a wait state. Am I missing something?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249067#4249067
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249067
16 years, 8 months
