[JBoss JIRA] (AS7-5714) JPA "Session Open Count" statistic appears to be bogus
by Jess Sightler (JIRA)
Jess Sightler created AS7-5714:
----------------------------------
Summary: JPA "Session Open Count" statistic appears to be bogus
Key: AS7-5714
URL: https://issues.jboss.org/browse/AS7-5714
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.2.Final (EAP)
Reporter: Jess Sightler
Assignee: Scott Marlow
Priority: Minor
After running a small sample app, Session Open Count in the admin console displays 900006. Session close count is 1 (as expected). Memory usage does not significantly increase.
The sample app exposes an EntityManager like this:
@Produces
public EntityManager getEntityManager() {
System.out.println("Getting entity manager!");
return entityManager;
}
A JAX-RS service then injects the entity manager, and performs a few simple queries:
@Inject
private EntityManager entityManager;
@GET()
@Produces("text/plain")
public String sayHello() {
try {
userTransaction.begin();
Car car = new Car();
car.setCarName("Name: " + System.currentTimeMillis());
entityManager.persist(car);
Car car2 = new Car();
car2.setCarName("Name: " + System.currentTimeMillis());
entityManager.persist(car2);
for (int i = 0; i < 900000; i++) {
Query q = entityManager.createQuery("select c from Car c");
List<Car> resultList = q.getResultList();
for (Car c : resultList) {
System.out.println("Car: " + c);
}
}
return "stub";
}
I don't see any way that this could actually be opening this many sessions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-5818) Fix cache control headers on FF
by Heiko Braun (JIRA)
Heiko Braun created AS7-5818:
--------------------------------
Summary: Fix cache control headers on FF
Key: AS7-5818
URL: https://issues.jboss.org/browse/AS7-5818
Project: Application Server 7
Issue Type: Feature Request
Components: Console, Domain Management
Reporter: Heiko Braun
Assignee: Heiko Braun
Fix For: 7.2.0.Alpha1
The last modified header seems to force FF to send a revalidation upon every request. This is not necessary and causes additional traffic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-4692) Review SecurityContext associations
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-4692:
-------------------------------------
Summary: Review SecurityContext associations
Key: AS7-4692
URL: https://issues.jboss.org/browse/AS7-4692
Project: Application Server 7
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
We should re-review the approach we take for security context association within AS7 containers.
Back at the time of AS 3 it fairly reliable to assume a 1:1 mapping of thread and client with the incoming connection being allocated it's own thread, this is no longer automatically the case and different containers can use different threading models e.g. using Executors to handle asynchronous requests.
The problem with using a ThreadLocal approach is that every time a container diverges from the 1:1 mapping of thread and client that container needs to work around the issue of an invalid SecurityContext association.
One possibility is to pass responsibility for managing the context to the container although this then introduces the question of how it is passed from container to container. This issue needs to consider this further.
Also need to review further how the security context can be created at all entry points to the server and how it can be manually switched now that we use SASL on entry for remote calls we do now have the opportunity for equivalent behaviour at the entry point for both web and ejb type calls - in the past we only had this opportunity for web based calls and would only create a security context on entering the interceptors for the EJB calls.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-4693) Revisit authenticated user / authorized user split
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-4693:
-------------------------------------
Summary: Revisit authenticated user / authorized user split
Key: AS7-4693
URL: https://issues.jboss.org/browse/AS7-4693
Project: Application Server 7
Issue Type: Task
Components: Remoting, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
When establishing a connection a remote user can specify the user they want to be authorized as which can be different to the user they authenticate as, e.g. a user with appropriate permissions may want to connect as an administrator or a user given access to someone elses account may want to connect as them.
We need to re-visit this including validation that they can connect as the user they are asking to.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months