[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Testsuite Compilation failed
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS==
===
NOTE: Sourceforge pserver cvs access is now using the backup server -
so these results are for yesterdays code.
===
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:1035:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\jbossmq\test\SecurityUnitTestCase.java:1085:
warning: stop() in java.lang.Thread has been deprecated
[javac] t1.stop();
[javac]^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:86:
warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated
[javac] if( conn instanceof HttpsURLConnection )
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:91:
warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated
[javac] HttpsURLConnection httpsConn = (HttpsURLConnection) conn;
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\service\HttpsClient.java:91:
warning: com.sun.net.ssl.HttpsURLConnection in com.sun.net.ssl has been deprecated
[javac] HttpsURLConnection httpsConn = (HttpsURLConnection) conn;
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:99:
warning: com.sun.net.ssl.SSLContext in com.sun.net.ssl has been deprecated
[javac] SSLContext sslCtx = null;
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:102:
warning: com.sun.net.ssl.SSLContext in com.sun.net.ssl has been deprecated
[javac] sslCtx = SSLContext.getInstance("TLS");
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:111:
warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated
[javac] String algorithm = KeyManagerFactory.getDefaultAlgorithm();
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:112:
warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated
[javac] KeyManagerFactory keyMgr =
KeyManagerFactory.getInstance(algorithm);
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:112:
warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated
[javac] KeyManagerFactory keyMgr =
KeyManagerFactory.getInstance(algorithm);
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:114:
warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated
[javac] algorithm = TrustManagerFactory.getDefaultAlgorithm();
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:115:
warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated
[javac] TrustManagerFactory trustMgr =
TrustManagerFactory.getInstance(algorithm);
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:115:
warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated
[javac] TrustManagerFactory trustMgr =
TrustManagerFactory.getInstance(algorithm);
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\HttpsUnitTestCase.java:117:
warning: com.sun.net.ssl.TrustManager in com.sun.net.ssl has been deprecated
[javac] TrustManager[] trustMgrs = trustMgr.getTrustManagers();
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\LoginModulesUnitTestCase.java:295:
warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been
deprecated
[javac] root.setPriority(XLevel.TRACE);
[javac] ^
[javac]
F:\jboss\jboss-head\testsuite\src\main\org\jboss\test\security\test\LoginModulesUnitTestCase.java:515:
cannot resolve symbol
[javac] symbol : class MBeanServer
[javac] location: class
RE: [JBoss-dev] Deadlock issue with SQL Server and other databases
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Jeremy Boynes > Sent: Saturday, June 21, 2003 4:58 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Deadlock issue with SQL Server and other > databases > > > > > > Are you sure this couldn't be avoided by using Instance Per > Transaction + > > SERIALIZABLE + Commit C? > > > > If you think about it, you'd realize that this just pushes the > deadlock into > the database resulting in rollbacks. This is the multi-instance model > described in the spec, but is not the way JBoss is configured by default. > > I happen to think making the default configuration multi-instance > would be a > little more disruptive than making the single-instance config we use now > work correctly. > We've been doing multi-instance since JBoss 2.4. Many customers and users use this feature successfully. > > If so, I'm worried that if you expand row-locking to happen > > during finder queries, you'll break a lot of applications. > > That would be the same concern I expressed in the original post ;-) > Again, since 2.4 > But again, row-locking is meant to imply locking. The bug is that we only > actually do it on the queries issued by LoadEntity and > LoadRelation, and not > on all the queries we execute. This leads to inconsistent locking and > ultimately, the deadlock. > > If people wish to use READ_COMMITTED, then simply don't turn on > row-locking. > But users use it that way. Since we don't have a distributed entity cache in 3.2, they use READ-COMMITTED + row-locking in a cluster. In fact there is no reason to use row-locking when you're using commit-option 'A' anyways since JBoss handles the locking. So why change things? Again, instance-per-transaction + SERIALIZABLE + Commit B or C gives you the same behavior doesn't it? > > > > We do have a mechanism to denote read-only invocations, at least on the > > Entity Bean level. > > Do we? I thought we only had read-only flags at the entity and > method level, > and they do not cover the dynamic nature of the usage. For example, when I > call findByPrimaryKey, I may be intending to just read from the > returned EJB > or to update some values; the future usage determines the type of lock to > take during the query. > > > I would like a plan from you on what kind of metadata > > needs to flow within the context of an invocation. I have done > > some work on > > how contextual information should flow throughout the system > with the AOP > > framework, but it probably needs to be expanded. A usecase > from you would > > help in this arena. > > > See above > You can only define read-only methods for Entity beans, but there's no reason we couldn't expand it to Session beans. Push and pop read-only in a thread local. There's some use cases for this to optimize ECPerf better as well. This should really be a JB4 thing though and really a separate issue > > Do not commit this change into the 3.2 branch until it has been fully > > documented by you within HEAD and fully reviewed by the > > community. We have > > to be very careful on how we apply fundamental changes to a maintainence > > release like 3.2.x. Other wise we may hinder our users from > > upgrading to a > > higher maintainence release because something as fundamental as > > locking has > > changed. > > > > The purpose of the original post _was_ to bring this to the > attention of the > community. > > This is a bug fix, not a fundamental change or conflicting > enhancement, and > is entirely appropriate for a maintenance release (at least Scott and I > thought so). Not fixing bugs in a timely manner is a hurdle to adoption in > general and not what one expects from an open source project. > Bug fixing is one thing, but changing fundamental behavior is another. Row-locking has been around since 2001 when I committed it to CVS. Some users rely on the fact that finder calls do not lock when row-locking is set. Ok, I reread your post and as I understand it you just want to add FOR UPDATE(or equivalent) to sql in the CMP engine. I was a bit worried you were going to change the app-server-level locking schemes too. Still, users are a bit touchy when it comes to locking. Again, SERIALIZABLE + instance per-transaction + commit B/C should work, shouldn't it? And again, row-locking is not used with commit option 'A'. Sorry to be nit-picky, but I want to avoid another flood of locking questions yet again. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock issue with SQL Server and other databases
> > Are you sure this couldn't be avoided by using Instance Per Transaction + > SERIALIZABLE + Commit C? > If you think about it, you'd realize that this just pushes the deadlock into the database resulting in rollbacks. This is the multi-instance model described in the spec, but is not the way JBoss is configured by default. I happen to think making the default configuration multi-instance would be a little more disruptive than making the single-instance config we use now work correctly. > If so, I'm worried that if you expand row-locking to happen > during finder queries, you'll break a lot of applications. That would be the same concern I expressed in the original post ;-) But again, row-locking is meant to imply locking. The bug is that we only actually do it on the queries issued by LoadEntity and LoadRelation, and not on all the queries we execute. This leads to inconsistent locking and ultimately, the deadlock. If people wish to use READ_COMMITTED, then simply don't turn on row-locking. > > We do have a mechanism to denote read-only invocations, at least on the > Entity Bean level. Do we? I thought we only had read-only flags at the entity and method level, and they do not cover the dynamic nature of the usage. For example, when I call findByPrimaryKey, I may be intending to just read from the returned EJB or to update some values; the future usage determines the type of lock to take during the query. > I would like a plan from you on what kind of metadata > needs to flow within the context of an invocation. I have done > some work on > how contextual information should flow throughout the system with the AOP > framework, but it probably needs to be expanded. A usecase from you would > help in this arena. > See above > Do not commit this change into the 3.2 branch until it has been fully > documented by you within HEAD and fully reviewed by the > community. We have > to be very careful on how we apply fundamental changes to a maintainence > release like 3.2.x. Other wise we may hinder our users from > upgrading to a > higher maintainence release because something as fundamental as > locking has > changed. > The purpose of the original post _was_ to bring this to the attention of the community. This is a bug fix, not a fundamental change or conflicting enhancement, and is entirely appropriate for a maintenance release (at least Scott and I thought so). Not fixing bugs in a timely manner is a hurdle to adoption in general and not what one expects from an open source project. Jeremy --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock issue with SQL Server and other databases
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Jeremy Boynes > Sent: Saturday, June 21, 2003 12:17 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] Deadlock issue with SQL Server and other databases > > > This bug indicates how a deadlock can occur between two threads > reading and > writing the same data: > http://sourceforge.net/tracker/index.php?func=detail&aid=758108&gr > oup_id=228 > 66&atid=376685 > > This is a hybrid deadlock where one thread gets blocked in the > database and > the other in the app server. As a result neither systems' > deadlock detection > works and the application hangs until the transaction times out. > > This can happen when: > * The database uses shared-read (S) locks on read and exclusive (X) locks > on writes. > * The database retains S locks for the duration of the transaction; for > example, if the database isolation level is raised to SERIALIZABLE > * The application reads data from the database before modifying it > Are you sure this couldn't be avoided by using Instance Per Transaction + SERIALIZABLE + Commit C? > The row-locking option in CMP is meant to avoid such issues by > ensuring the > rows being read are locked so that updates can be performed > later. However, > this option only affects the query executed for ejbLoad, and not other > queries such as finders. > > I will be fixing this in 3.2 and HEAD by ensuring that the row-locking > option affects all queries executed by the CMP engine. This will cure the > deadlock scenario described in the bug, but may impact the application: > Now does your deadlock scenario only happen with Isolation level SERIALIZABLE? If so, I'm worried that if you expand row-locking to happen during finder queries, you'll break a lot of applications. If your deadlock scenario is only under SERIALIZABLE I suggest we investigate having metadata that can mark the transaction isolation level of the database connection so that we can avoid doing a lock during finder queries for READ_COMMITTED isolation levels and lower. It is my experience that the general use of JBoss and DBs is with READ_COMMITTED isolation. I'd hate to see concurrency suffer under READ_COMMITTED scenarios just to obtain completeness when the isolation level is SERIALIZABLE. Let's make sure that this doesn't happen. > * If two threads read data in different orders, then a deadlock can > occur at the database level; this is currently true at the EJB > level anyway. If this happens, the database's deadlock detection > may cause one query to be terminated (SQL Server does this) > resulting in rollback > > * Because all data is locked on read, concurrency will be reduced. > This is the expected behaviour for applications running at a > SERIALIZABLE isolation level. For those databases that support > it (e.g. SQL Server), I will try and make row-locking use update > locks rather than exclusive locks to allow reader threads to > proceed. However, without a mechanism to denote read-only > invocations, this may not have tangible benefit. > We do have a mechanism to denote read-only invocations, at least on the Entity Bean level. I would like a plan from you on what kind of metadata needs to flow within the context of an invocation. I have done some work on how contextual information should flow throughout the system with the AOP framework, but it probably needs to be expanded. A usecase from you would help in this arena. > I am posting this to the lists early as a heads-up of a change in > behaviour > as a consequence of fixing this bug. A change note will be posted when the > fix is committed. > Do not commit this change into the 3.2 branch until it has been fully documented by you within HEAD and fully reviewed by the community. We have to be very careful on how we apply fundamental changes to a maintainence release like 3.2.x. Other wise we may hinder our users from upgrading to a higher maintainence release because something as fundamental as locking has changed. Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-580636 ] Jetty should use the JBoss tmp dir
Bugs item #580636, was opened at 2002-07-12 18:21 Message generated for change (Comment added) made by french_c You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=580636&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty should use the JBoss tmp dir Initial Comment: There have been a number of reports regaurding the content of unpackaged wars being removed and causing the web app to fail. One cause of removal is cron jobs cleaning out the system tmp directory which is what Jetty uses for its unpackaged wars. These should be placed into the JBoss server//tmp directory by default so that users have more control over this. -- Comment By: Jens Schumann (french_c) Date: 2003-06-21 19:59 Message: Logged In: YES user_id=661964 Glad I just repeated the summary. Stupid me. I was reading the follow ups only ;( -- Comment By: Jens Schumann (french_c) Date: 2003-06-21 18:56 Message: Logged In: YES user_id=661964 Most Unix platforms I know of default to /tmp for java.io.tmpdir. Hence this is a major problem since you will also have a default cron job which will wipe out old files from /tmp usually. So if you have web applications on your box which won't be touched that often (such as the JMX Console) you will run into FileNotFoundExceptions. -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-09-19 12:09 Message: Logged In: YES user_id=44062 Alternately, shouldn't JBoss set the java.io.tmpdir property to be it's own temp directory? That way anything that uses temp File creation will use the right directory - including Jetty. -- Comment By: Mike Finn (mikefinn) Date: 2002-08-29 18:47 Message: Logged In: YES user_id=418562 This has been a source of irritation for me as well. This is how I have gotten around it. It's a hack, but you can "fool" Jetty to use any directory for its deploy tmp, just by overriding java.io.tmpdir (like with JAVA_OPT). Jetty appears to the the only thing in the source tree using java.io.tmpdir, and this does not seem to have any ill-effects. Of course, a more permanent solution is needed, but how to have Jetty read a *JBoss* config setting (like paths) in a portable manner? It seems overriding java.io.tmpdir might be the best solution, but where to do it? Main? Server? Mike -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=580636&group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-758484 ] Create SubContext not replicated
Bugs item #758484, was opened at 2003-06-21 19:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=758484&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Jens Schumann (french_c) Assigned to: Nobody/Anonymous (nobody) Summary: Create SubContext not replicated Initial Comment: Create SubContext (and possibly destroySubcontext) is not replicated across HA JNDI Trees. This way object bind/rebind/etc calls will be broadcasted, however the tree will be out of sync. Example: Use the code in bug #758476 and execute it (with two different jndi names) on both nodes while both are running. Lets say the code was executed on node one first, on node two second. Now on node one the sub context contains both objects, node two will have its own object only. After that replication within this sub context will work as expected. Tested on JBoss 3.0.7. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=758484&group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-758204 ] Jsr-77: Missing StatisticsProvider attribute
Bugs item #758204, was opened at 2003-06-20 15:42 Message generated for change (Comment added) made by sreich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=758204&group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Laurent Etiemble (letiemble) Summary: Jsr-77: Missing StatisticsProvider attribute Initial Comment: MacOSX, JDK 1.4.1, JBoss 3.2.2 TOT. JavaMailResource returns falsee as the value for StatisticsProvider as opposed to JSR-77 section JSR77.6.17. To verify, launch the JMX console. -- >Comment By: Stefan Reich (sreich) Date: 2003-06-21 10:40 Message: Logged In: YES user_id=429729 How about turning this bug report into an enhancement request then. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-06-21 02:47 Message: Logged In: YES user_id=437455 According to the JSR77.6.1, the StatisticsProvider interface is optional. But if a managed object implements it, it must provides the corresponding Stats interface. JSR77.6.1 "The Performance Data Framework consists of the StatisticsProvider model, which any managed object may implement, the Stats interfaces, which specify standard performance attribute semantics for each managed object type, and the Statistic interfaces which provide specific interfaces for representing the common performance data types." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=758204&group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-758476 ] SubContexts and Cluster Node getState
Bugs item #758476, was opened at 2003-06-21 19:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=758476&group_id=22866
Category: Clustering
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jens Schumann (french_c)
Assigned to: Nobody/Anonymous (nobody)
Summary: SubContexts and Cluster Node getState
Initial Comment:
Node getState() fails in case the HA JNDI Tree contains
a sub context. As soon as a new node joins the cluster
state synchronisation will result in a
java.io.NotSerializableException. I have been looking
in the source and it seems that a simple getState()
returning the Hashtable is not the appropriate way to
synchronize a the JNDI Tree. The required changes may
involve changes in the NamingContext/NamingServer
classes, so I stopped looking for a solution.
---
Example:
Execute the follwing code on one node while the second
node is not active:
Hashtable properties = {HA JNDI Properties}
InitialContext ctx = new InitialContext(properties);
Context subCtx = (Context)ctx.createSubcontext("Test")
subCtx.rebind("foo","bar");
Start the second node.
Tested against 3.0.7.
-
2003-06-21 17:57:44,354 ERROR
[org.jboss.ha.framework.server.HAPartitionImpl.DefaultPartition]
GetState failed
java.io.NotSerializableException:
org.jboss.ha.framework.server.HAPartitionImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
java.util.Hashtable.writeObject(Hashtable.java:802)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:795)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at java.util.HashMap.writeObject(HashMap.java:958)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:795)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.jboss.ha.framework.server.HAPartitionImpl.objectToByteBuffer(HAPartitionImpl.java:123)
at
org.jboss.ha.framework.server.HAPartitionImpl.getState(HAPartitionImpl.java:311)
at
org.javagroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:460)
at
org.javagroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:294)
at
org.javagroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:513)
at org.javagroups.JChannel.up(JChannel.java:841)
at
org.javagroups.stack.ProtocolStack.up(ProtocolStack.java:302)
at
org.javagroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:318)
at
org.javagroups.stack.Protocol.passUp(Protocol.java:435
[JBoss-dev] [ jboss-Bugs-580636 ] Jetty should use the JBoss tmp dir
Bugs item #580636, was opened at 2002-07-12 18:21 Message generated for change (Comment added) made by french_c You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=580636&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty should use the JBoss tmp dir Initial Comment: There have been a number of reports regaurding the content of unpackaged wars being removed and causing the web app to fail. One cause of removal is cron jobs cleaning out the system tmp directory which is what Jetty uses for its unpackaged wars. These should be placed into the JBoss server//tmp directory by default so that users have more control over this. -- Comment By: Jens Schumann (french_c) Date: 2003-06-21 18:56 Message: Logged In: YES user_id=661964 Most Unix platforms I know of default to /tmp for java.io.tmpdir. Hence this is a major problem since you will also have a default cron job which will wipe out old files from /tmp usually. So if you have web applications on your box which won't be touched that often (such as the JMX Console) you will run into FileNotFoundExceptions. -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-09-19 12:09 Message: Logged In: YES user_id=44062 Alternately, shouldn't JBoss set the java.io.tmpdir property to be it's own temp directory? That way anything that uses temp File creation will use the right directory - including Jetty. -- Comment By: Mike Finn (mikefinn) Date: 2002-08-29 18:47 Message: Logged In: YES user_id=418562 This has been a source of irritation for me as well. This is how I have gotten around it. It's a hack, but you can "fool" Jetty to use any directory for its deploy tmp, just by overriding java.io.tmpdir (like with JAVA_OPT). Jetty appears to the the only thing in the source tree using java.io.tmpdir, and this does not seem to have any ill-effects. Of course, a more permanent solution is needed, but how to have Jetty read a *JBoss* config setting (like paths) in a portable manner? It seems overriding java.io.tmpdir might be the best solution, but where to do it? Main? Server? Mike -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=580636&group_id=22866 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deadlock issue with SQL Server and other databases
This bug indicates how a deadlock can occur between two threads reading and writing the same data: http://sourceforge.net/tracker/index.php?func=detail&aid=758108&group_id=228 66&atid=376685 This is a hybrid deadlock where one thread gets blocked in the database and the other in the app server. As a result neither systems' deadlock detection works and the application hangs until the transaction times out. This can happen when: * The database uses shared-read (S) locks on read and exclusive (X) locks on writes. * The database retains S locks for the duration of the transaction; for example, if the database isolation level is raised to SERIALIZABLE * The application reads data from the database before modifying it The row-locking option in CMP is meant to avoid such issues by ensuring the rows being read are locked so that updates can be performed later. However, this option only affects the query executed for ejbLoad, and not other queries such as finders. I will be fixing this in 3.2 and HEAD by ensuring that the row-locking option affects all queries executed by the CMP engine. This will cure the deadlock scenario described in the bug, but may impact the application: * If two threads read data in different orders, then a deadlock can occur at the database level; this is currently true at the EJB level anyway. If this happens, the database's deadlock detection may cause one query to be terminated (SQL Server does this) resulting in rollback * Because all data is locked on read, concurrency will be reduced. This is the expected behaviour for applications running at a SERIALIZABLE isolation level. For those databases that support it (e.g. SQL Server), I will try and make row-locking use update locks rather than exclusive locks to allow reader threads to proceed. However, without a mechanism to denote read-only invocations, this may not have tangible benefit. I am posting this to the lists early as a heads-up of a change in behaviour as a consequence of fixing this bug. A change note will be posted when the fix is committed. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] HEAD and Tomcat 4.1.24
Hello! I get following exception with HEAD and Tomcat 4.1.24 when executing the first JSP of the JMX-Console. The ant.jar is only in /server/default/lib. Subsequent calls only show other classes in the exception (org/apache/tools/ant/types/FilterSet, ...). What is going on here? java.lang.LinkageError: duplicate class definition: org/apache/tools/ant/Task at org.apache.jasper.compiler.Compiler.getProject(Compiler.java:152) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:273) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.jboss.web.catalina.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:236) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) CU Thomas --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-756466 ] JNDI context is wrong inside setEntityContext()
Bugs item #756466, was opened at 2003-06-18 12:08
Message generated for change (Comment added) made by loubyansky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=756466&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Alexei Yudichev (sflexus)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: JNDI context is wrong inside setEntityContext()
Initial Comment:
W2k or Linux, JDK 1.4.1_02, JBoss 3.2.1.
Assuming the following method is a business method of a
CMP Bean called Product:
abstract public class ProductBean extends MMSBean
implements EntityBean {
[...]
public MMSObject getMMSObject() {
return getMmsimage();
}
[...]
}
getMmsimage() is a CMR 1-to-1 field of ProductBean.
MMSImage Bean implementation:
class abstract public class MMSImageBean extends
MMSObjectBean implements EntityBean {
[...]
}
public abstract class MMSObjectBean extends MMSBean
{
[...]
public void setEntityContext(EntityContext
entityContext) {
super.setEntityContext(entityContext);
try {
contentOwnerHome = (ContentOwnerHome) new
InitialContext().lookup("java:
comp/env/ejb/mms/ContentOwnerLocal");
} catch (NamingException ex) {
throw new EJBException(ex);
}
}
[...]
}
A NameNotFoundException is thrown inside
MMSObjectBean.setEntityContext() (see stack trace is
attached). After carefull investigation it appeared that
inside MMSImageBean.setEntityContext() (which is
actually MMSObjectBean.setEntityContext()) the JNDI
ENC context of Product bean is active despite of the
current bean is MMSImageBean! After adding to Product
bean an ejb reference to ContentOwner bean exception
disappeared. Of course, ejb reference to ContentOwner
bean does exist for MMSImage bean.
If MMSObjectBean.setEntityContext() is invoked as a
result of a different invocation chain, for example as a
result of finding MMSImage by primary key, the JNDI
context is set up properly.
--
>Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-06-21 16:57
Message:
Logged In: YES
user_id=543482
Could you, please, try again with Branch_3_2 from CVS? (you
can update only JDBCCMRFieldBridge to test)
Thank you,
alex
--
Comment By: Alexei Yudichev (sflexus)
Date: 2003-06-20 11:08
Message:
Logged In: YES
user_id=345880
No it is not. Just downloaded and installed 3.2.2RC1 and still
experience the same problem. Stack trace is attached.
--
Comment By: Adrian Brock (ejort)
Date: 2003-06-18 13:50
Message:
Logged In: YES
user_id=9459
This was fixed in the 3.2.2RC1 release
Regards,
Adrian
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=756466&group_id=22866
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
