[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 updated AS7-5904:
------------------------------
Fix Version/s: 7.2.0.Alpha1
7.1.4.Final (EAP)
Affects Version/s: 7.1.3.Final (EAP)
> 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
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> 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, 11 months
[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, 11 months
[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, 11 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
12 years, 11 months