[JBoss-dev] [ jboss-Bugs-569305 ] Server IP detection causes problems
Bugs item #569305, was opened at 2002-06-15 07:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569305group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Terrell (j3110) Assigned to: Nobody/Anonymous (nobody) Summary: Server IP detection causes problems Initial Comment: By default, on some Linux distributions, for performance and other reasons (some interfaces have dynamic IP's but the hosts ip shouldn't change), the host name of the local machine is configured to point to 127.0.0.1. When connecting through JNDI from a remote machine, the IP set in jndi.properties is overwritten with 127.0.0.1 on the client side. Obviously, this causes the client to fail connecting to the server. Other servers, Apache for example, warn the user that this is probably undesired behavior and allow a way to manually override the local IP with an option in the configuration files. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569305group_id=22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 15-June-2002
Number of tests run: 612
Successful tests: 611
Errors:1
Failures: 0
[time of test: 15 June 2002 0:29 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-569313 ] ejb-ql parser broken in 3.0.1RC1
Bugs item #569313, was opened at 2002-06-15 18:32
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=569313group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: ejb-ql parser broken in 3.0.1RC1
Initial Comment:
This query fragment works fine in 3.0.0:
query
query-method
method-namefindForUser/method-name
method-params
method-paramjava.lang.String/method-param
method-paramjava.lang.String/method-param
/method-params
/query-method
result-type-mappingRemote/result-type-mapping
ejb-ql![CDATA[select distinct object(p) from User as u,
in (u.userRoles) as r, in (r.rolePrivs) as p where u.loginId = ?1 and
p.pcode = ?2]]/ejb-ql
/query
but fails in 3.0.1RC1 with the following error:
17:25:23,269 ERROR [URLDeploymentScanner] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$Deployed
URL@e8fea58d{ url=file:/Users/steve/EnterpriseJava/jboss-3.0/
build/output/jboss-3.0.1RC1/server/sacha/deploy/sacha.jar,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not deploy
file:/Users/steve/EnterpriseJava/jboss-3.0/build/output/jboss-
3.0.1RC1/server/sacha/deploy/sacha.jar; - nested throwable:
(org.jboss.deployment.DeploymentException: Error compiling
ejbql; - nested throwable:
(org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered
User at line 1, column 32.
Was expecting one of:
IN ...
ABSTRACT_SCHEMA ...
))
User is a legitimate abstract schema name.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=569313group_id=22866
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Joining to JBoss Development
Dear all, I would like to join to the development of JBOSS and I think I need a clear vision of the overall architecture of the system. Could anybody send me a document describing such issue? On the other hand, there is any development task needing help? I think the best way to start is to collaborate with somebody. Looking forward to receive your comments, Best Regards, Simón Díaz Megías ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-569439 ] page truncated while loading
Bugs item #569439, was opened at 2002-06-15 19:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569439group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paolo Devoti (devotip) Assigned to: Nobody/Anonymous (nobody) Summary: page truncated while loading Initial Comment: see http://bugzilla.mozilla.org/show_bug.cgi?id=148639 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=569439group_id=22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 15-June-2002
Number of tests run: 612
Successful tests: 611
Errors:1
Failures: 0
[time of test: 15 June 2002 12:29 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:77: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:121: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:143: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/DurableSubscriberTest.java:161: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/ExceptionListenerTest.java:63: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:111: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:113: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:168: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MultipleDurableSubscribers.java:170: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [execmodules] tf.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:74: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:116: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] 2 errors [execmodules] 21 warnings BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/testsuite/build.xml:761: Compile failed, messages should have been provided. Total time: 2 minutes 4 seconds ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-563988 ] interrupted threads cannot load classes
Bugs item #563988, was opened at 2002-06-03 11:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=563988group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Harald Gliebe (hagl)
Assigned to: Nobody/Anonymous (nobody)
Summary: interrupted threads cannot load classes
Initial Comment:
I get the following Error when deploying the attached file:
java.lang.Error: Illegal Lock usage, t=Thread[Thread-
3,5,jboss], owner=null
at
org.jboss.mx.loading.UnifiedLoaderRepository$Reentrant
Lock.release(UnifiedLoaderRepository.java:852)
at
org.jboss.mx.loading.UnifiedLoaderRepository.synchroni
ze(UnifiedLoaderRepository.java:227)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass
(UnifiedLoaderRepository.java:126)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass
(UnifiedClassLoader.java:285)
at java.lang.ClassLoader.loadClass
(ClassLoader.java:262)
at java.lang.ClassLoader.loadClassInternal
(ClassLoader.java:322)
at test.TestThread.run(TestThread.java:19)
The error is caused by the
UnifiedLoaderRepository.synchronize and
unsynchronize methods that try to release the
reentrantLock even if they couldn't acquire it (i.e. if
acquire threw an InterruptedException). Further
investigations shows that the ReentrantLock throws this
exception if the incoming thread has the interrupt flag
set.
To allow class-loading in such situations (e.g. for
loadClassInternal as in the example) I changed the
synchronize and unsynchronize methods to clear the
interrupt flag before acquiring the lock and restoring it
after relesing the lock (see attached patch). This works
for the example and has no negative effects on the
TestSuite. However, I don't know what other side-effects
these changes might have.
To reproduce the exception above run the 3.0 minimal
configuration, copy test.jar to minimal/lib and test-
service.xml to minimal/deploy
Changes to UnifiedLoaderRepository:
// then on the classloader (resource ordering
problem).
// We solve this by using a reentrant lock.
+ boolean interrupted=false;
try
{
// Only one thread can pass this barrier
// Other will accumulate here and let passed one
at a time to wait on the classloader,
// like a dropping sink
+
+ // clear the interrupt flag
+ interrupted = Thread.currentThread().interrupted();
reentrantLock.acquire();
while (!isThreadAllowed(Thread.currentThread()))
@@ -225,13 +229,19 @@
// This new thread will not be allowed and will wait
() on the classloader object,
// releasing its lock.
reentrantLock.release();
+ // restore the interrupt flag
+ if (interrupted) {
+ Thread.currentThread().interrupt();
+ }
}
}
private void unsynchronize(ClassLoader cl)
{
+ boolean interrupted=false;
try
{
+ interrupted =
Thread.currentThread().interrupted();
reentrantLock.acquire();
// Reset the current thread only if we're not
reentrant
@@ -244,6 +254,9 @@
finally
{
reentrantLock.release();
+if (interrupted) {
+Thread.currentThread
().interrupt();
+}
// Notify all threads waiting on this classloader
// This notification must be after the
reentrantLock's release() to avoid this scenario:
--
Comment By: Scott M Stark (starksm)
Date: 2002-06-15 17:56
Message:
Logged In: YES
user_id=175228
The suggested work around makes sense and has been
applied to main and branch_3_0
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=563988group_id=22866
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-520892 ] RH hangs during shutdown - cache resize
Bugs item #520892, was opened at 2002-02-21 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=520892group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: RH hangs during shutdown - cache resize Initial Comment: RH from CVS, 20020219, W2K When a cache resize occurs during shutdown, JBoss hangs. Stack trace: 2002-02-21 09:48:56,410 DEBUG [org.jboss.system.ServiceCreator] unregistered caossloader for: jboss:service=HAJNDI 2002-02-21 09:48:56,410 DEBUG [org.jboss.system.ServiceController] removing service: jboss:service=HASessionState 2002-02-21 09:48:56,410 DEBUG [org.jboss.system.ServiceController] removing jboss:service=HASessionState from server 2002-02-21 09:48:56,410 INFO [org.jboss.ha.hasessionstate.server.HASessionStateServi ce] Stopping 2002-02-21 09:48:56,410 INFO [org.jboss.ha.hasessionstate.server.HASessionStateServi ce] Stopped 2002-02-21 09:48:56,410 DEBUG [org.jboss.system.ServiceCreator] unregistered caossloader for: jboss:service=HASessionState 2002-02-21 09:48:56,410 DEBUG [org.jboss.system.ServiceController] removing service: jboss:service=DefaultPartition 2002-02-21 09:48:56,410 DEBUG [org.jboss.system.ServiceController] removing jboss:service=DefaultPartition from server 2002-02-21 09:48:56,410 INFO [org.jboss.ha.framework.server.ClusterPartition] Stopping 2002-02-21 09:48:56,410 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Stopping HAPartition: DefaultPartition 2002-02-21 09:48:56,410 INFO [org.jboss.ha.framework.server.HAPartitionImpl.DefaultP artition] Closing partition DefaultPartition 2002-02-21 09:48:56,441 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean MaintenanceHistoryEB: old capacity = 100, new capacity = 50 2002-02-21 09:49:06,644 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean AttributeEB: old capacity = 100, new capacity = 50 2002-02-21 09:50:14,191 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean MaintenanceTaskEB: old capacity = 100, new capacity = 50 2002-02-21 09:50:16,425 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean DocumentEB: old capacity = 100, new capacity = 50 2002-02-21 09:50:18,472 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean TriggerHistoryEB: old capacity = 100, new capacity = 50 2002-02-21 09:50:41,815 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean MaintenanceEB: old capacity = 100, new capacity = 50 2002-02-21 09:51:05,441 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean UserEB: old capacity = 100, new capacity = 50 2002-02-21 09:51:33,986 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean FacilityEB: old capacity = 100, new capacity = 50 2002-02-21 09:51:46,173 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean MaintenanceMaterialEB: old capacity = 100, new capacity = 50 2002-02-21 09:51:46,736 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean MaterialEB: old capacity = 100, new capacity = 50 2002-02-21 09:51:48,439 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean ScheduleEB: old capacity = 100, new capacity = 50 2002-02-21 09:52:02,176 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean GlobalSettingsEB: old capacity = 100, new capacity = 50 2002-02-21 09:52:55,360 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean OIDCounterEB: old capacity = 100, new capacity = 50 2002-02-21 09:53:06,767 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean TaskHistoryEB: old capacity = 100, new capacity = 50 2002-02-21 09:53:33,705 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean MaintenanceTriggerEB: old capacity = 100, new capacity = 50 2002-02-21 09:53:49,173 DEBUG [org.jboss.ejb.plugins.EnterpriseContextCachePolicy] Resized cache for bean ModuleEB: old capacity = 100, new capacity = 50 2002-02-21 09:58:03,998 DEBUG [org.jboss.pool.PoolGCThread] gc thread running gc 2002-02-21 09:58:03,998 DEBUG [org.jboss.pool.PoolGCThread] gc thread pool: NoTransDS isTimeToCleanup()true 2002-02-21 09:58:03,998 DEBUG [org.jboss.pool.PoolGCThread] gc thread pool: FabviewDB isTimeToCleanup()true 2002-02-21 09:58:03,998 DEBUG [org.jboss.pool.PoolGCThread] gc thread pool: JmsXA isTimeToCleanup()true 2002-02-21 09:58:03,998 DEBUG [org.jboss.pool.PoolGCThread] gc thread pool: PMSystemDB isTimeToCleanup()true 2002-02-21 09:58:03,998 DEBUG
[JBoss-dev] [ jboss-Bugs-567381 ] Multiple hot-redploys cause JVM panic
Bugs item #567381, was opened at 2002-06-11 05:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=567381group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Simon Stewart (shs96c) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple hot-redploys cause JVM panic Initial Comment: Using Sun's JDK 1.4 and the final release of both JBoss 3.0+Jetty and JBoss 3.0+catalina attempting to redeploy an app numerous times will eventually cause the JVM to panic. I've not tested this with a proper EAR file, but on a set of exploded directories. Having said this, from the nature of the problem, I don't think that's the cause. Technical information: JDK 1.4 (from Sun) Debian Linux (latest testing) with 2.2.17 kernel JBoss 3.0.0 final Steps required to reproduce: 1) Start JBoss as normal and deploy an app. 2) Make a change to one of the files and touch application.xml 3) Wait until JBoss has redeployed the app. 4) Repeat steps 2 to 4 ;) -- Comment By: Scott M Stark (starksm) Date: 2002-06-15 17:59 Message: Logged In: YES user_id=175228 There is nothing we should be able to do in Java code to cause a vm panic. 1.4 on linux so far has proven to be unstable for use with JBoss. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=567381group_id=22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-551335 ] NullPointerException when stopping ORB
Bugs item #551335, was opened at 2002-05-02 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=551335group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Alistair Sheffield (asheffield) Assigned to: Nobody/Anonymous (nobody) Summary: NullPointerException when stopping ORB Initial Comment: OS: Windows 2000 JDK: 1.4.0 I started JBoss by running the run.bat; once it had started I then used CTRL-C to shut it down, without doing anything else in between. A NullPointerException occurred when trying to stop the ORB service. The console output is attached. Alistair -- Comment By: Scott M Stark (starksm) Date: 2002-06-15 18:01 Message: Logged In: YES user_id=175228 The jacorb version has since been updated. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=551335group_id=22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail?
Sure, that makes some sense. There are few issues that need to be addressed with the deployment logic and I plan on looking into next week. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Neuer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 15, 2002 5:25 PM Subject: Re: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail? Perhaps it makes sense to have a way to mark an MBean as essential or optional, and treat failures of the latter as loggable, non-fatal errors. Dave Neuer --- Scott M Stark [EMAIL PROTECTED] wrote: This is a good feature for exactly the case you mention, jboss-service.xml being screwed up. Why put the mbeans together if you don't want this behavior? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon To: [EMAIL PROTECTED] Sent: Friday, June 14, 2002 12:05 PM Subject: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail? Just what the subject says: Why does one MBean failure cause the entire deployment unit to fail? If I have put several MBeans into user-service.xml (or whatever) of which the last one fails to start, why do we stop/destroy all of the others? This also happens from time to time with jboss-service.xml, say of Naming can't start because of a port conflict (perhaps because the jvm did not die when it was asked to). When this does happen the server will shutdown and exit. I can see how this might be useful to force users to deal with problems with the deployment unit, but I think that logging an ERROR is a better option, only failing the deployment unit if none of the MBeans have deployed, or rather throw the exception but don't stop/destroy/unregistered beans which have been started. This behavior is more desirable in my opinion, as it allows for easier debugging by allowing the user to inspect the logs, and the state of the other MBeans to possibly resolve the issue, possibly by changing config and starting by hand. With the system as is, the only options are to comment the config, or configure/create each MBean by hand. both kinda suck, the latter much more. Is there a reason to fail all MBeans when one MBean fails? --jason __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail?
I agree with jason that we should always continue deployment as far as possible and undo as little as possible. We also need to make all problems extremely visible through jmx and possibly logging. With proper dependency specifications nothing that depends on a unsuccessfully deployed mbean will start anyway, including your application, so I don't see the problem in leaving the state as is, and letting the administrator fiddle with it to try to fix things through jmx. david jencks On 2002.06.15 20:25:55 -0400 Dave Neuer wrote: Perhaps it makes sense to have a way to mark an MBean as essential or optional, and treat failures of the latter as loggable, non-fatal errors. Dave Neuer --- Scott M Stark [EMAIL PROTECTED] wrote: This is a good feature for exactly the case you mention, jboss-service.xml being screwed up. Why put the mbeans together if you don't want this behavior? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon To: [EMAIL PROTECTED] Sent: Friday, June 14, 2002 12:05 PM Subject: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail? Just what the subject says: Why does one MBean failure cause the entire deployment unit to fail? If I have put several MBeans into user-service.xml (or whatever) of which the last one fails to start, why do we stop/destroy all of the others? This also happens from time to time with jboss-service.xml, say of Naming can't start because of a port conflict (perhaps because the jvm did not die when it was asked to). When this does happen the server will shutdown and exit. I can see how this might be useful to force users to deal with problems with the deployment unit, but I think that logging an ERROR is a better option, only failing the deployment unit if none of the MBeans have deployed, or rather throw the exception but don't stop/destroy/unregistered beans which have been started. This behavior is more desirable in my opinion, as it allows for easier debugging by allowing the user to inspect the logs, and the state of the other MBeans to possibly resolve the issue, possibly by changing config and starting by hand. With the system as is, the only options are to comment the config, or configure/create each MBean by hand. both kinda suck, the latter much more. Is there a reason to fail all MBeans when one MBean fails? --jason __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail?
The problem I see is having to establish dependcies on every critical service. Naming for instance is used by nearly every bean so we would have to further complicate the correct setup of services. I would rather have fail fast semantics than uncertain running but not working services. There has got to be a valid use case for the fix it on the fly behavior we are moving to. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, June 15, 2002 6:09 PM Subject: Re: [JBoss-dev] Why does one MBean failure cause the entire deployment unit to fail? I agree with jason that we should always continue deployment as far as possible and undo as little as possible. We also need to make all problems extremely visible through jmx and possibly logging. With proper dependency specifications nothing that depends on a unsuccessfully deployed mbean will start anyway, including your application, so I don't see the problem in leaving the state as is, and letting the administrator fiddle with it to try to fix things through jmx. david jencks ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-564854 ] subscription-durability not optional
Bugs item #564854, was opened at 2002-06-05 06:40
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=564854group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Daniel Sieroka (sieroka)
Assigned to: Scott M Stark (starksm)
Summary: subscription-durability not optional
Initial Comment:
16:41:30,354 ERROR [URLDeploymentScanner] Failed
to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$
DeployedUR
L@ca5ceb4d{ url=file:/C:/jboss-
3.0.0/server/default/deploy/admin.ear,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Error in ejb-
jar.xml for Message Driven Bean
ejb/ClientEventsMessageBean: expe
cted one subscription-durability tag
The dtd:
!ELEMENT message-driven-destination (destination-
type,
subscription-durability?)
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=564854group_id=22866
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-563988 ] interrupted threads cannot load classes
Bugs item #563988, was opened at 2002-06-03 11:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=563988group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Harald Gliebe (hagl)
Assigned to: Scott M Stark (starksm)
Summary: interrupted threads cannot load classes
Initial Comment:
I get the following Error when deploying the attached file:
java.lang.Error: Illegal Lock usage, t=Thread[Thread-
3,5,jboss], owner=null
at
org.jboss.mx.loading.UnifiedLoaderRepository$Reentrant
Lock.release(UnifiedLoaderRepository.java:852)
at
org.jboss.mx.loading.UnifiedLoaderRepository.synchroni
ze(UnifiedLoaderRepository.java:227)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass
(UnifiedLoaderRepository.java:126)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass
(UnifiedClassLoader.java:285)
at java.lang.ClassLoader.loadClass
(ClassLoader.java:262)
at java.lang.ClassLoader.loadClassInternal
(ClassLoader.java:322)
at test.TestThread.run(TestThread.java:19)
The error is caused by the
UnifiedLoaderRepository.synchronize and
unsynchronize methods that try to release the
reentrantLock even if they couldn't acquire it (i.e. if
acquire threw an InterruptedException). Further
investigations shows that the ReentrantLock throws this
exception if the incoming thread has the interrupt flag
set.
To allow class-loading in such situations (e.g. for
loadClassInternal as in the example) I changed the
synchronize and unsynchronize methods to clear the
interrupt flag before acquiring the lock and restoring it
after relesing the lock (see attached patch). This works
for the example and has no negative effects on the
TestSuite. However, I don't know what other side-effects
these changes might have.
To reproduce the exception above run the 3.0 minimal
configuration, copy test.jar to minimal/lib and test-
service.xml to minimal/deploy
Changes to UnifiedLoaderRepository:
// then on the classloader (resource ordering
problem).
// We solve this by using a reentrant lock.
+ boolean interrupted=false;
try
{
// Only one thread can pass this barrier
// Other will accumulate here and let passed one
at a time to wait on the classloader,
// like a dropping sink
+
+ // clear the interrupt flag
+ interrupted = Thread.currentThread().interrupted();
reentrantLock.acquire();
while (!isThreadAllowed(Thread.currentThread()))
@@ -225,13 +229,19 @@
// This new thread will not be allowed and will wait
() on the classloader object,
// releasing its lock.
reentrantLock.release();
+ // restore the interrupt flag
+ if (interrupted) {
+ Thread.currentThread().interrupt();
+ }
}
}
private void unsynchronize(ClassLoader cl)
{
+ boolean interrupted=false;
try
{
+ interrupted =
Thread.currentThread().interrupted();
reentrantLock.acquire();
// Reset the current thread only if we're not
reentrant
@@ -244,6 +254,9 @@
finally
{
reentrantLock.release();
+if (interrupted) {
+Thread.currentThread
().interrupt();
+}
// Notify all threads waiting on this classloader
// This notification must be after the
reentrantLock's release() to avoid this scenario:
--
Comment By: Scott M Stark (starksm)
Date: 2002-06-15 17:56
Message:
Logged In: YES
user_id=175228
The suggested work around makes sense and has been
applied to main and branch_3_0
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=563988group_id=22866
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Oracle BLOB handling - FIXED?
I just committed the code from patch [ 525663 ] CMP and oracle blobs. Can some with Oracle check if the code actually works? The following command will execute a new test I added which has a field of every type: ./build.sh -Dtest=org.jboss.test.cmp2.simple.SimpleUnitTestCase one-test You'll need to change the datasource and datasource-mapping in the src/resources/cmp2/simple/META-INF/jbosscmp-jdbc.xml file. This won't work perfectly for every database vendor, because some vendor's don't support millisecond precise time and nanosecond precise timestamp values. The test that is important for blobs is testObjectValue. -dain ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
