[JBoss JIRA] Commented: (JBCACHE-679) Deadlock using transactional JBossCache with Hibernate
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-679?page=comments#action_12345034 ]
Manik Surtani commented on JBCACHE-679:
---------------------------------------
Yegor, have you tried this with the latest in the 1.4.0 series?
> Deadlock using transactional JBossCache with Hibernate
> ------------------------------------------------------
>
> Key: JBCACHE-679
> URL: http://jira.jboss.com/jira/browse/JBCACHE-679
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Replication
> Affects Versions: 1.3.0.SP2
> Environment: SUSE 10.1, kernel 2.6.15 SPM, JDK 1.5.0_06, PostgreSQL 8.0.1
> Reporter: Yegor Yenikyeyev
> Assigned To: Manik Surtani
> Priority: Critical
> Attachments: nloptc.zip
>
>
> It seems like we discovered an unpredictable Hibernate and/or TreeCache behavior after upgrade JBossCache from 1.2.4SP2 to JBossCache 1.3.0SP2. For now I can witness that the same problem appears with 1.4.0CR2. I do not think that it's Hibernate-only or TreeCache-only issue but I do think it's a kind of integration issue or misunderstanding of how TreeCache transaction isolation is implemented.
> Our application works in clustered environment and we use JBossCache as L2 cache solution for Hibernate 3.1.3 (I checked this with 3.2.0CR2 as well). Our settings for JBossCache are
> REPL_SYNC, READ_COMMITED and our target business object methods (f1 and f2) have PROPAGATION_REQUIRED and PROPAGATION_REQUIRES_NEW. Our JDBC driver is 3.0 compliant.
> Our objects hierarchy is like: Occasion contains link to Round and Round contains link to Tournament. Round is NOT configured as "lazy" field in Occasion mapping b/c we always need to have it initialized.
>
> Here is in short what we try to do in our application:
>
> (1) Transaction1: Call f1 (PROPAGATION_REQUIRED) method of a business object and it causes Occasion1 to be loaded via a cachable query. After that Hibernate initializes Occasion1.round field and loads Round1.
> (2) Transaction1: Hibernate puts loaded Occasion1 and Round1 in L2 cache.
> (3) Transaction1: TreeCache creates com/companyname/Occasion/com.companyname.Occasion#1 region and obtains WriteLock (WL1)
> (4) Transaction1: TreeCache creates com/companyname/Round/com.companyname.Round#1 region and obtains WriteLock (WL2)
> (5) Transaction1: Do some business logic stuff
> (6) Transaction1: We expect current transaction to be long and we want to change status of Occasoin1 in DB very quickly. At this point we need an exclusive lock for appropriate row in DB table to change the status and commit it. In order to do this we call f2 (PROPAGATION_REQUIRES_NEW) which suppose to be a REALLY short transaction which release lock on the DB row as fast as possible.
>
> (7) Transaction2: Transaction1 SUSPENDED at this point. We call HibernateTemplate (we use Spring as well) to load Occasion1 for update with LockMode.UPGRADE flag and get exclusive lock.
> (8) Transaction2: Hibernate does NOT check for an instance of Occasion1 in L2 cache ( I suppose it's b/c we obviously do want to lock it for update )
> (9) Transaction2: Hibernate does check for an instance of Round1 in L2 cache and it calls get() on TreeCache to obtain com/companyname/Round/com.companyname.Round#1
> (10) Transaction2: At this point 1.3.0SP2 tries to obtain ReadLock for com/companyname/Round/com.companyname.Round#1 and it can't b/c there is a WL for that node in suspended Transaction1 !!! It can't obtain ReadLock for Round#1 anyhow!
> (11) Transaction2: Stuck waiting for WL2 to be released in TreeCache but it can't be released as soon as Transaction1 suspended and waits for Transaction2 to finish.
>
> Obviously this situation is ridiculous - a legal sequence of operations causes a deadlock on TreeCache. We do not expect com/companyname/Round/com.companyname.Round#1 to be visible in Transaction2 b/c we use READ_COMMITED but WL2 must not affect Transaction2 in this way. As soon as TreeCache prevents other transactions from reading com/companyname/Round/com.companyname.Round#1 it must not tell other transactions that the node exists to keep READ_COMMITED behavior consistent. For now it simply preventing everybody from using PROPAGATION_REQUIRES_NEW.
> The described scenario works with 1.2.4SP2 without a problem and I have serious concern that READ_COMMITED strategy is really implemented in v1.2.4 but at least the behavior is more consistent comparing to v1.3.0. As far as i understand this is result of JBCACHE-218 bugfix.
>
> We tried to change PROPAGATION_REQUIRES_NEW to PROPAGATION_NESTED and take advantage of nested transactions. We assume that com/companyname/Round/com.companyname.Round#1 would be available in a nested Transaction2 from Transaction1. But PROPAGATION_NESTED isn't supported by current JBossTransaction implementation (see line 209 in TxManager.java from 4.0.4.GA).
> We could change isolation to READ_UNCOMMITED but it's simply impossible in many other places of our application.
> We could make a trick and load Occasion1 with Round1 in a separate Transaction0 before starting Transaction1 but we HAVE to use LRU policy. That is why there is no chance for us to make sure that eviction won't happen between Transaction0 and Transaction1. If it happened then we are in the same situation as described above.
> Finally we could stop using Transaction2 but our application is intend to handle large amount of traffic and as soon as Transaction1 takes up to 3sec (comparing to 50ms for Transaction2) we might get up to 700-1000 transactions on queue waiting for table row lock to be released and we just can't allow this.
>
> From what I see in Hibernate TreeCache sources and I have no idea how to avoid the situation described above. One of my developers told me that probably it's possible to put stuff into L2 cache on transaction commit which would decrease WL time and resolve the issue with the deadlock. Honestly I'm seriously concerned how it applies to existing Hibernate. I think small issues like performance issue of loading the same object during 1 transaction more then once can be resolved by using L1 cache or JDBC driver abilities. But I guess there are a plenty of work to make this working for cachable queries.
> Another option I see is to do a trick and put values for Round1 and Occasion1 into a new region for Transaction2 if we know that Transaction1 suspended and owns WLs for various nodes. I really do not like this way b/c in fact it's not a pure pessimistic locking. But the issue described before is worse price for "pure" READ_COMMITED strategy. In fact it showstopper assuming there is no way to use PROPAGATION_NESTED.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBPM-741) JbpmSchedulerThread does not terminate the scheduler/command threads properly
by Alejandro Guizar (JIRA)
JbpmSchedulerThread does not terminate the scheduler/command threads properly
-----------------------------------------------------------------------------
Key: JBPM-741
URL: http://jira.jboss.com/jira/browse/JBPM-741
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.1
Reporter: Alejandro Guizar
Fix For: jBPM 3.1.3
The implementation of SchedulerThread and CommandExecutorThread in 3.1.1 does not provide a mechanism to exit the run() method, allowing the Thread to exit properly and release any resources it is holding.
This becomes an issue for perm gen in JBoss AS and other containers.
For SchedulerThread, keepRunning (bool) should be public or provide mutators, so whatever launches the Thread can modify it.
For CommandExecutorThread, the while(true) in run() should be changed to something like SchedulerThread uses and, of course, provide mutators to the loop control variable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Commented: (JBPM-345) persisting process definition with superstate hibernate problems
by Dimitar Marinov (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-345?page=comments#action_12345024 ]
Dimitar Marinov commented on JBPM-345:
--------------------------------------
A simple modification in the ProcessDefinition.hbm.xml file soved the problem for me. Just replace
<list name="nodes" cascade="all">
with
<list name="nodes" cascade="all" where="SUPERSTATE_ is null">
after that ProcessDefinitions include only nodes which don't belong to any SuperState.
Best regards,
Dimitar Marinov
> persisting process definition with superstate hibernate problems
> ----------------------------------------------------------------
>
> Key: JBPM-345
> URL: http://jira.jboss.com/jira/browse/JBPM-345
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.0.1
> Reporter: James Depoorter
> Assigned To: Tom Baeyens
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When persisting a process definition with superstates and reloading, hibernate has trouble loading "root" nodes mixed with superstates. The superstate 'overwrites' the link. This is due to the re-use of the collectionindex column for both nodes within superstates, and nodes within process definition, and the fact that EVERY node has a link to the process definition.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Resolved: (JBXB-33) Util Class: Util method to pass a StringList/SchemaBindingResolver/Error Handler
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBXB-33?page=all ]
Thomas Diesler resolved JBXB-33.
--------------------------------
Resolution: Out of Date
> Util Class: Util method to pass a StringList/SchemaBindingResolver/Error Handler
> ---------------------------------------------------------------------------------
>
> Key: JBXB-33
> URL: http://jira.jboss.com/jira/browse/JBXB-33
> Project: JBoss XML Binding (JBossXB)
> Issue Type: Feature Request
> Reporter: Anil Saldhana
> Assigned To: Alexey Loubyansky
>
> This is a feature request from JBoss Web Services Tools.
> In order for me to migrate the parsing of multiple schema files to the JBossXB layer, I need the following method in the Util class:
> public static XSModel loadSchema(StringList xsdList, SchemaBindingResolver schemaResolver,SchemaBindingErrorHandler schemaErrorHandler)
> Note: SchemaBindingErrorHandler can be a JBossXB class that internally holds org.apache.xerces.xni.parser.XMLErrorHandler as an implementation detail.
>
> I did test the following method:
> ===========================================================================
> /**
> * Loads a Xerces based Schema Model provided a list of Strings representing
> * schema files. Also a SchemaBindingResolver can be passed to the parser.
> * @param xsdURL
> * @param schemaResolver
> * @return
> */
> public static XSModel loadSchema(StringList xsdList, SchemaBindingResolver schemaResolver)
> {
> XSImplementation impl = getXSImplementation();
> XSLoader schemaLoader = impl.createXSLoader(null);
> if(schemaResolver != null)
> {
> setResourceResolver(schemaLoader, schemaResolver);
> }
> XSModel model = schemaLoader.loadURIList(xsdList);
> if(model == null)
> {
> throw new IllegalArgumentException("Invalid schema");
> }
> return model;
> }
> ======================================================
> I did not make the change because I need to pass an instance of org.apache.xerces.xni.parser.XMLErrorHandler to the Xerces parsers
> and I felt that you would be able to find a better way of passing an error handler to the parsers (while hiding the Xerces details like
> XMLErrorHandler as an implementation detail).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBPM-696) Field Instanciator problems
by Shai Bentin (JIRA)
Field Instanciator problems
---------------------------
Key: JBPM-696
URL: http://jira.jboss.com/jira/browse/JBPM-696
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.1
Environment: WinXP, Linux running on JBoss Application Server 4.0.3SP1, JDK1.5.0_06
Reporter: Shai Bentin
Assigned To: Tom Baeyens
Priority: Minor
Fix For: jBPM 3.1.2
The method getValue() is see two problems, one is jdk5 related the other is just an idea.
In jdk5 doing if (type.isAssignableFrom(Set.class)) and such yields a 'false' even when it is supposed to be true...
if we would write the same if in reverse:
Set.class.isAssignableFrom(type) we will ge the desired reuslt.
The other issue is, if we know the super type why do we impose a specific implementation, i.e. if we have a Collection, why do we impose an ArrayList. We have the user's type and we know it is of type collection so why don't we instanciate the requested type....
Here is how I propose to write this method:
public static Object getValue(Class type, Element propertyElement) {
// parse the value
Object value = null;
try {
if ( type == String.class ) {
value = propertyElement.getText();
} else if ( (type==Integer.class) || (type==int.class) ) {
value = new Integer( propertyElement.getTextTrim() );
} else if ( (type==Long.class) || (type==long.class) ) {
value = new Long( propertyElement.getTextTrim() );
} else if ( (type==Float.class ) || (type==float.class) ) {
value = new Float( propertyElement.getTextTrim() );
} else if ( (type==Double.class ) || (type==double.class) ) {
value = new Double( propertyElement.getTextTrim() );
} else if ( (type==Boolean.class ) || (type==boolean.class) ) {
value = Boolean.valueOf( propertyElement.getTextTrim() );
} else if ( (type==Character.class ) || (type==char.class) ) {
value = new Character( propertyElement.getTextTrim().charAt(0) );
} else if ( (type==Short.class ) || (type==short.class) ) {
value = new Short( propertyElement.getTextTrim() );
} else if ( (type==Byte.class ) || (type==byte.class) ) {
value = new Byte( propertyElement.getTextTrim() );
} else if (List.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (List)type.newInstance());
} else if (Set.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (Set)type.newInstance());
} else if (Collection.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (Collection)type.newInstance());
} else if (Map.class.isAssignableFrom(type)) {
value = getMap(propertyElement, (Map)type.newInstance());
} else if ( type==Element.class ) {
value = propertyElement;
} else {
Constructor constructor = type.getConstructor(new Class[]{String.class});
if ( (propertyElement.isTextOnly())
&& (constructor!=null) ) {
value = constructor.newInstance(new Object[]{propertyElement.getTextTrim()});
}
}
} catch (Exception e) {
log.error("couldn't parse the bean property value '" + propertyElement.asXML() + "' to a '" + type.getName() + "'" );
throw new JbpmException( e );
}
return value;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBPM-758) DbPersistenceService needs update for new Hibernate version
by Thomas Klute (JIRA)
DbPersistenceService needs update for new Hibernate version
-----------------------------------------------------------
Key: JBPM-758
URL: http://jira.jboss.com/jira/browse/JBPM-758
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.2
Environment: jboss AS 4.0.4, hibernate 3.1 or hibernate 3.2
Reporter: Thomas Klute
Assigned To: Tom Baeyens
Fix For: jBPM 3.1.3
Release of JDBC connections changed with hibernate version > 3.0.
DbPersistenceService now throws exception when trying to close a hibernate session (because in was closed automatically when the transaction committed).
The exception happens every few seconds when using the jbpm scheduler-service.
See below for stack trace.
See http://www.hibernate.org/250.html#A31 for a detailed description of hibernate-changes regarding JDBC connections.
FYI: The exception does not roll back the transaction, because it has already been committed.
Please adapt the code to the new hibernate behaviour. Maybe just comment out the "throw" of the exception.
I have no idea what code would work with old _and_ new hibernate versions.
We just got the problem integrating jbpm into a jboss AS 4.0.4 using hibernate 3.2.
...
2006-09-28 16:11:53,996 DEBUG [org.jbpm.persistence.db.DbPersistenceService] creating hibernate session
2006-09-28 16:11:53,998 DEBUG [org.hibernate.jdbc.JDBCContext] TransactionFactory reported no active transaction; Synchronization not registered
2006-09-28 16:11:53,998 DEBUG [org.hibernate.impl.SessionImpl] opened session at timestamp: 4749118316527616
2006-09-28 16:11:53,998 DEBUG [org.jbpm.persistence.db.DbPersistenceService] beginning hibernate transaction
2006-09-28 16:11:53,998 DEBUG [org.hibernate.transaction.JTATransaction] Looking for UserTransaction under: UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] Obtained UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] begin
2006-09-28 16:11:54,000 DEBUG [org.hibernate.transaction.JTATransaction] Began a new JTA transaction
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.JDBCContext] successfully registered Synchronization
2006-09-28 16:11:54,000 DEBUG [org.jbpm.scheduler.impl.SchedulerThread] checking for timers
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection
2006-09-28 16:11:54,000 DEBUG [org.hibernate.SQL] select timer0_.ID_ as col_0_0_ from JBPM_TIMER timer0_ where (timer0_.EXCEPTION_ is null) and timer0_.ISSUSPENDED_<>1 order by timer0_.DUEDATE_ asc
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] exhausted results
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] closing iterator
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2006-09-28 16:11:54,001 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
2006-09-28 16:11:54,002 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService@15a9173
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] commit
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] Committed JTA UserTransaction
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.svc.Services.close(Services.java:211)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.JbpmContext.close(JbpmContext.java:139)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
2006-09-28 16:11:54,003 ERROR [STDERR] Caused by: org.hibernate.SessionException: Session was already closed
2006-09-28 16:11:54,003 ERROR [STDERR] at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
2006-09-28 16:11:54,003 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
2006-09-28 16:11:54,003 ERROR [STDERR] ... 4 more
2006-09-28 16:11:54,003 ERROR [org.jbpm.svc.Services] problem closing service 'persistence'
org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
at org.jbpm.svc.Services.close(Services.java:211)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.hibernate.SessionException: Session was already closed
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
... 4 more
2006-09-28 16:11:54,003 INFO [org.jbpm.scheduler.impl.SchedulerThread] runtime exception while executing timers
org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session}
at org.jbpm.svc.Services.close(Services.java:223)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
at org.jbpm.svc.Services.close(Services.java:211)
... 3 more
Caused by: org.hibernate.SessionException: Session was already closed
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
... 4 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBSEAM-404) Exception handling rules
by Louis Coetzee (JIRA)
Exception handling rules
------------------------
Key: JBSEAM-404
URL: http://jira.jboss.com/jira/browse/JBSEAM-404
Project: JBoss Seam
Issue Type: Feature Request
Reporter: Louis Coetzee
Seam provides the @Redirect annotation for use on Exception classes. It provides an attribute to specify the target viewId to redirect to once the exception has been thrown. It would be good if this view Id can be specified dynamically.
e.g.
@Name("napException")
@ApplicationException(rollback=true)
@Redirect(viewId = "#{napException.viewId}")
public class NAPException extends Exception implements Serializable {
or in xml
<from-view-id>/xxx.jsp</from-view-id>
<from-exception>com.myapp.NAPException</from-exception>
<to-view-id>/error.jsp</to-view-id>
<redirect/>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months