January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6365) Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6365?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-6365: ----------------------------------- If this is still a bug in the latest AS7 sources and latest Hibernate, a https://hibernate.onjira.com/browse/HHH jira should be created for the defect. [Download the latest AS7 nightly build|http://community.jboss.org/thread/167590] and recreate with that. If you can recreate, then update the Hibernate jars (see [note here for some guidance|https://docs.jboss.org/author/display/AS72/JPA+Reference+Guide#J...]) to use the latest Hibernate 4.1 release (currently 4.1.9). This NPE in the Hibernate-Infinispan integration code may of been fixed already. Let us know. > Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6365 > URL: https://issues.jboss.org/browse/AS7-6365 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Reporter: Fredrik Lagerblad > Assignee: Scott Marlow > > The caches in the 'infinispan' subsystem configured with <transaction mode="NONE"/> get stuck in state= CLEARING when you perform a programmatic evict() on them to clear the caches. (Using e.g. em.getEntityManagerFactory().getCache().evictAll() ) > > The problem seem to lie within the class 'org.hibernate.cache.infinispan.impl.BaseRegion, where the 'checkValid' method fails to clear the cache (and set back the state to VALID). The reason it fails is due to that it calls: cacheAdapter.withinTx() , which in turn tries to get the TransactionManager from the cache (which seems to be null for these non-transactional caches), and then NPEs on the tm.begin(); The NPE is caught and logs out "Could not invalidate region: null", and never set the state in VALID. So from thereon the caches are in an Invalid state and is not used anymore by Infinispan, thus leading to much performance. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1574: --------------------------- Fix Version/s: 3.2.7 3.3 Awaiting your pull requests for master and the 3.2 branch > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 3.2.7, 3.3 > > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT

by Bernd Koecke (JIRA)

[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ] Bernd Koecke commented on AS7-6408: ----------------------------------- Hello Tomaz, thanks a lot for fixing this so fast :). I tried the :add-protocol operation and it works like a charm. But it works only when I'm using a batch run. When I send /subsystem=jgroups/stack=udp:add(transport={"type"=>"UDP","socket-binding"=>"jgroups-udp"}) outside a batch, I get an error that the protocol list is missing. In earlier versions I was able to define the protocol list like the transport attribute, it wasn't a list of string. But it works well when I use :add-protocol lines after adding the stack and putting a batch - run-batch around it. I checked this with my current version, which doesn't include your fix. I will check the old way, when I get your fix from git. Thanks again, Bernd > Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT > --------------------------------------------------------------------------- > > Key: AS7-6408 > URL: https://issues.jboss.org/browse/AS7-6408 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.2.0.Alpha1 > Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013) > Reporter: Bernd Koecke > Assignee: Tomaz Cerar > Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml > > > When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment. > When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1548) UNICAST2: send STABLE message after 'last received' message

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1548: -------------------------------- You can always use the DONT_BUNDLE flag; as a matter of fact, [1] will actually bundle OOB messages by default. Bundling has nothing to do with the last-message-lost issue; an unbundled OOB message can also be lost as the last message, leading to the same issue. [1] https://issues.jboss.org/browse/JGRP-1564 > UNICAST2: send STABLE message after 'last received' message > ----------------------------------------------------------- > > Key: JGRP-1548 > URL: https://issues.jboss.org/browse/JGRP-1548 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > Contrary to UNICAST, which acks every message, UNICAST2 never acks messages, but only asks the sender to retransmit a message when a gap has been detected. > However, the drawback of this (negative ack) mechanism is the so called last-message-dropped problem: when A sends messages [1..5] to B, but 5 is dropped by the transport, as A doesn't retransmit messages until it gets a retransmission request from B, B only gets messages [1..4]. > B will *not* ask A to retransmit message 5, as B doesn't know A *sent* message 5 in the first place. > If A doesn't send message 6 for B to detect 5 is missing and asking A for retransmission, B won't get that message. > The way this is currently handled is with stable messages. A STABLE message is sent from B to A every stable_interval ms or whenever M bytes from A have been received. In the worst case, B will have to wait stable_interval ms until it finally receives message 5 from A. > SOLUTION: > In addition to time and size based STABLE messages, we could send a STABLE message whenever the batch of messages removed from the receive window has completed and the receive window is empty. > This would send a STABLE message immediately when a single message has been received (and no other messages from A are in the receive window), but it would send another STABLE message only when all (e.g.) 200 messages from A have been processed and the receive window is empty. > With this new mechanism, we could even remove the time-based STABLE messages ! > Example: > - At time T0, messages M1 and M2 are received. A STABLE message for M2 is sent. > - At T+500 (ms), messages M3-M100 are received. A STABLE message for M100 is sent > - At T+1500, M101 is received. A STABLE message for M101 is sent. > - At T+2000, M102 is received. A STABLE message for M102 is sent. > - At T+2010, M103-M500 are received. A STABLE message for M500 is sent > (Note that the example above didn't take size-based STABLE messages into account) > This is similar to the ACK based scheme in UNICAST where we only send an ack for the last message in a batch (or for a single message if not batch has been received). > This new mechanism needs to be configurable: if enabled, the time-based STABLE mechanism would be disabled. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-1574: ------------------------------ Affects Version/s: 3.2.6 > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-22) Drools index files are getting created out of control and consume all of the hard drive space

by Jyothi Alapati (JIRA)

[ https://issues.jboss.org/browse/DROOLS-22?page=com.atlassian.jira.plugin.... ] Jyothi Alapati updated DROOLS-22: --------------------------------- Description: Drools index files are getting created out of control and consume all of the hard drive space. It used to consume 20MB for index files, but in this case, it consumed 5GB of hard disk space and stopped working. Note: Deleting the old index files except the latest solved this problem, but we want this to be prevented, instead of deleting the index files manually. was: Drools index files are getting created out of control and consume all of the hard drive space. It used to consume 20MB for index files, but in this case, it consumed 5GB of hard disk space and stopped working. Note: Deleting the old index files except the latest solved this problem, but we want to this to be prevented, instead of deleting the index files manually. > Drools index files are getting created out of control and consume all of the hard drive space > --------------------------------------------------------------------------------------------- > > Key: DROOLS-22 > URL: https://issues.jboss.org/browse/DROOLS-22 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Jyothi Alapati > Assignee: Mark Proctor > Attachments: repository.xml, workspace.xml > > > Drools index files are getting created out of control and consume all of the hard drive space. It used to consume 20MB for index files, but in this case, it consumed 5GB of hard disk space and stopped working. > Note: Deleting the old index files except the latest solved this problem, but we want this to be prevented, instead of deleting the index files manually. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-1574: ------------------------------ Description: Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-22) Drools index files are getting created out of control and consume all of the hard drive space

by Jyothi Alapati (JIRA)

[ https://issues.jboss.org/browse/DROOLS-22?page=com.atlassian.jira.plugin.... ] Jyothi Alapati updated DROOLS-22: --------------------------------- Attachment: repository.xml workspace.xml Attaching the repository.xml and workspace.xml > Drools index files are getting created out of control and consume all of the hard drive space > --------------------------------------------------------------------------------------------- > > Key: DROOLS-22 > URL: https://issues.jboss.org/browse/DROOLS-22 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Jyothi Alapati > Assignee: Mark Proctor > Attachments: repository.xml, workspace.xml > > > Drools index files are getting created out of control and consume all of the hard drive space. It used to consume 20MB for index files, but in this case, it consumed 5GB of hard disk space and stopped working. > Note: Deleting the old index files except the latest solved this problem, but we want to this to be prevented, instead of deleting the index files manually. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Radim Vansa (JIRA)

Radim Vansa created JGRP-1574: --------------------------------- Summary: ThreadPool rejection policy detecting stuck threads Key: JGRP-1574 URL: https://issues.jboss.org/browse/JGRP-1574 Project: JGroups Issue Type: Feature Request Reporter: Radim Vansa Assignee: Bela Ban -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-1574: ------------------------------ Assignee: Radim Vansa (was: Bela Ban) > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Reporter: Radim Vansa > Assignee: Radim Vansa > -- 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

11 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2013