[JBoss JIRA] (AS7-5904) CLONE - JGroups startup before ISPN startup causes HotRod connector startup fail
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/AS7-5904?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro moved JBPAPP-10377 to AS7-5904:
--------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5904 (was: JBPAPP-10377)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: Clustering
(was: Infinispan)
Security: (was: Public)
Docs QE Status: (was: NEW)
> CLONE - JGroups startup before ISPN startup causes HotRod connector startup fail
> --------------------------------------------------------------------------------
>
> Key: AS7-5904
> URL: https://issues.jboss.org/browse/AS7-5904
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Radim Vansa
> Assignee: Paul Ferraro
>
> HotRod connector startup often fails in JDG 6.1.0.ER2. This is caused by early initialization of the JGroups stack, where the node can join cluster sooner than Infinispan is properly initialized, specifically sooner than the JGroupsTransport class initializes the JGroups channel and related RPC dispatcher.
> In some early phase of startup each node with HotRod connector inserts data with key nodeName/clusterName into __hotRodTopologyCache (this is a replicated one). The PutKeyValueCommand is broadcasted to all nodes in the cluster, including the node which joined the cluster but where the Infinispan has not started yet. As there is no RPC dispatcher on the destination node, the message gets discarded, but source node requesting GET_ALL reponses waits for the response for 4 minutes (default timeout) and then gets an exception failing the HotRod connector.
--
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
12 years, 1 month
[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
12 years, 1 month
[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
12 years, 1 month
[JBoss JIRA] (AS7-5903) OSGi tests may incorrectly assume that a given service is available
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5903:
-----------------------------------
Summary: OSGi tests may incorrectly assume that a given service is available
Key: AS7-5903
URL: https://issues.jboss.org/browse/AS7-5903
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 7.2.0.Alpha1
Similar to AS7-5828 there may be other tests that could potentially fail because of an invalid assumption that a given service is available. This may especially happen if the test before changes the framework startlevel.
--
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
12 years, 1 month