September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-525) postgresql-persistence-service.xml contains invalid SQL syntax

by Takayoshi Kimura (JIRA)

postgresql-persistence-service.xml contains invalid SQL syntax -------------------------------------------------------------- Key: JBMESSAGING-525 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525 Project: JBoss Messaging Issue Type: Bug Components: Configuration and Management Affects Versions: 1.0.1.CR4 Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1 Reporter: Takayoshi Kimura Assigned To: Ovidiu Feodorov Attachments: postgresql-persistence-service.xml.patch The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax. http://www.postgresql.org/docs/8.1/static/sql-update.html http://www.postgresql.org/docs/7.4/static/sql-update.html To fix this, simply remove the aliases from the SQL. -- 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, 8 months

3
11
0 / 0

[JBoss JIRA] Updated: (JBCACHE-644) FileCacheLoader fails if FQN contains illegal/too many characters

by Galder Zamarreno (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-644?page=all ] Galder Zamarreno updated JBCACHE-644: ------------------------------------- Priority: Major (was: Minor) changed priority in order for it to appear at the top of my tasks > FileCacheLoader fails if FQN contains illegal/too many characters > ----------------------------------------------------------------- > > Key: JBCACHE-644 > URL: http://jira.jboss.com/jira/browse/JBCACHE-644 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Cache loaders > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2 > Environment: Windows XP > Reporter: Amit Kasher > Assigned To: Galder Zamarreno > Fix For: 2.0.0 > > > When putting FQNs that are too long to become filenames, or that contain illlegal characters for filenames (semicolon, for example), the FileCacheLoader throws an IOException. > The FileCacheLoader should encode the FQN string so that it is a valid filename. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-650) SharedStoreCacheLoader

by Galder Zamarreno (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-650?page=all ] Galder Zamarreno resolved JBCACHE-650. -------------------------------------- Resolution: Done [JBCACHE-650] - SharedStoreCacheLoader refactored to SingletonStoreCacheLoader adding the ability to push the in-memory state to the underlying cache loader when assuming the coordinator role. Created AbstractDelegatingCacheLoader class that contains the basic delegating functionality. SingletonStoreCacheLoader and AsyncCacheLoader now extend this class. Necessary configuration options added and documentation has been updated to include explanation. Two singleton cache sample configurations added too. > SharedStoreCacheLoader > ---------------------- > > Key: JBCACHE-650 > URL: http://jira.jboss.com/jira/browse/JBCACHE-650 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Cache loaders > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2 > Reporter: Bela Ban > Assigned To: Galder Zamarreno > Fix For: 2.0.0 > > Original Estimate: 3 days > Time Spent: 4 days > Remaining Estimate: 0 minutes > > Reactive this loader, which stores modifications only if it is the current coordinator. In addition, it should (configurable via a flag) dump the entire in-memory contents into the file system, overwriting whatever is there, when it becomes coordinator. This is only possible though if no eviction has been defined -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-744) Expand CacheLoader API to support streaming state transfer

by Vladimir Blagojevic (JIRA)

Expand CacheLoader API to support streaming state transfer ---------------------------------------------------------- Key: JBCACHE-744 URL: http://jira.jboss.com/jira/browse/JBCACHE-744 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0, 1.3.0, 1.2 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.0.0 CacheLoader API prior to 2.0 does not support streaming state transfer feature implemented in Jgroups 2.4. In order to transfer application state to a receiving cache node we currently have to load entire state into memory and send it to a receiving cache node. Major limitation of this approach is that the state transfer that is very large (>total memory allocated by JVM) would result in OutOfMemoryException. For example, if a cacheloader is pointing to a huge DOM tree, whose aggregate size is 2GB (and which has partly been passivated to disk), then the state provider cacheloader node can simply iterate over the DOM tree (activating the parts which have been passivated out to disk), and write it to the OutputStream as it traverses the tree. The receiving cacheloader will simply read from the InputStream and reconstruct the tree on its side, possibly again passivating parts to disk. Rather than having to provide a 2GB byte[] buffer (besides the state, so the needed memory is ca 4GB temporarily), streaming state transfer transfers the state in chunks of N bytes (user configurable). In order to accomodate this feature CacheLoader API will be expanded to include the following methods: void storeEntireState(InputStream s); void storeState(Fqn subtree,InputStream s); void loadEntireState(OutputStream s); void loadState(Fqn subtree,OutputStream s); -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3717) correct TCL should be used before starting entity PMs

by Alexey Loubyansky (JIRA)

correct TCL should be used before starting entity PMs ----------------------------------------------------- Key: JBAS-3717 URL: http://jira.jboss.com/jira/browse/JBAS-3717 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.0.5.CR1 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so protected void startService() throws Exception { // before EntityContainer returns from the startService, its PM should be usable ListIterator iter = containerOrdering.listIterator(); while( iter.hasNext() ) { Container con = (Container) iter.next(); if(con.getBeanMetaData().isEntity()) { ClassLoader oldCl = SecurityActions.getContextClassLoader(); SecurityActions.setContextClassLoader(con.getClassLoader()); try { ((EntityContainer)con).getPersistenceManager().start(); } finally { // Reset classloader SecurityActions.setContextClassLoader(oldCl); } } } ... -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-565) Race Condition between Topic/Queue.getMessageCount and Deliver Thread

by Clebert Suconic (JIRA)

Race Condition between Topic/Queue.getMessageCount and Deliver Thread --------------------------------------------------------------------- Key: JBMESSAGING-565 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Alpha1 Reporter: Clebert Suconic Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Alpha2 This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point. QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread. PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder - firstPagingOrder deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination. While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries. To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow. I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. -- 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, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBAS-3728) Check ClassLoader comparisons

by Adrian Brock (JIRA)

Check ClassLoader comparisons ----------------------------- Key: JBAS-3728 URL: http://jira.jboss.com/jira/browse/JBAS-3728 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.0.5.CR1 Reporter: Adrian Brock Assigned To: Scott M Stark The codebase needs checking for other classloader comparisons similar to that found on the parent issue for the EJBContainer. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-139) The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.

by Kevin Conner (JIRA)

The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBTM-139 URL: http://jira.jboss.com/jira/browse/JBTM-139 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.2.2 -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-3715) 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)

by Dimitris Andreadis (JIRA)

1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit) ---------------------------------------------------------------------------------- Key: JBAS-3715 URL: http://jira.jboss.com/jira/browse/JBAS-3715 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Security, Test Suite Environment: Java Version 1.4.2_11 Java Vendor BEA Systems, Inc. Java VM Name BEA JRockit(R) Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 Java VM Info OS Name Linux OS Version 2.6.9-42.0.2.ELsmp OS Arch i386 Reporter: Dimitris Andreadis Assigned To: Anil Saldhana Fix For: JBossAS-4.0.5.GA testSRPLoginWithAuxChallenge Failure Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) The same test passes with Sun Jdk1.4 but I believe this is due to jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security local_policy.jar US_export_policy.jar Not updated to include unlimited crypto ability? -- 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, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-3723) on Windowns: org.jboss.test.jrmp.test fail with CNFE

by Prabhat Jha (JIRA)

on Windowns: org.jboss.test.jrmp.test fail with CNFE ---------------------------------------------------- Key: JBAS-3723 URL: http://jira.jboss.com/jira/browse/JBAS-3723 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab) Reporter: Prabhat Jha Under the package org.jboss.test.jrmp.test, follwoing test cases fail with ClassNotFoundException. DynLoadingFromSARUnitTestCase DynLoadingFromSARUnpackedUnitTestCase DynLoadingUnitTestCase javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55) Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:219) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at java.rmi.MarshalledObject.get(MarshalledObject.java:135) at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652) ... 18 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, 8 months

3
8
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006