Re: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
The serialization contract as dictated by the serialVersionID at which the class was fixed in 3.2 should be maintained. -- Scott Stark Chief Technology Officer JBoss Group, LLC Bill Burke wrote: I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804968 ] EJB-SQL conversion bug with OR
Bugs item #804968, was opened at 2003-09-12 11:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804968group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Joachim Van der Auwera (triathlon98) Assigned to: Nobody/Anonymous (nobody) Summary: EJB-SQL conversion bug with OR Initial Comment: Given the following EJBQL : SELECT OBJECT(o) FROM Weight o WHERE ( o.sale.reference = ?1 ) OR ( o.purchase.reference = ?2 ) OR ( o.declaration.reference = ?3 ) with a pk field unid_uoid is converted to the folowing SQL : SELECT t0_o.UNID_UOID FROM WEIGHT t0_o, WEIGHTGROUP t2_o_purchase, WEIGHTGROUP t1_o_sale, WEIGHTGROUP t3_o_declaration WHERE ((t1_o_sale.f_Reference = ?) OR (t2_o_purchase.f_Reference = ?) OR (t3_o_declaration.f_Reference = ?)) AND (t0_o.f_Purchase_UOID=t2_o_purchase.UNID_UOID AND t0_o.f_Sale_UOID=t1_o_sale.UNID_UOID AND t0_o.f_Declaration_UOID=t3_o_declaration.UNID_UOID) The correct SQL would be : SELECT t0_o.UNID_UOID FROM WEIGHT t0_o, WEIGHTGROUP t2_o_purchase, WEIGHTGROUP t1_o_sale, WEIGHTGROUP t3_o_declaration WHERE ( ((t1_o_sale.f_Reference = ?) AND t0_o.f_Sale_UOID=t1_o_sale.UNID_UOID ) OR ((t2_o_purchase.f_Reference = ?) AND t0_o.f_Purchase_UOID=t2_o_purchase.UNID_UOID) OR ((t3_o_declaration.f_Reference = ?) AND t0_o.f_Declaration_UOID=t3_o_declaration.UNID_UOID) ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804968group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] -Dtest=cmp2/perf
Could someone, please, check this testcase against current Branch_3_2? It fails for me with timeout. I wonder whether I broke it in my local copy. Thanks, alex --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
The 20% was for Local interfaces and it doesn't break compatibility. Sacha Labourey wrote: I agree, compatibility has already been broken between minor 3.2.x versions, so if it allows us to have 20% improvement, I would say: GO! The thinking about compatibility should occur before, not after and requires the establishment of more serious and stable rules (version_id, etc.)s -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: vendredi, 12. septembre 2003 01:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects You guys are talking about a 3.3 proxy talking to a 3.2 server? If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804968 ] EJB-SQL conversion bug with OR
Bugs item #804968, was opened at 2003-09-12 12:55 Message generated for change (Settings changed) made by loubyansky You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804968group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Joachim Van der Auwera (triathlon98) Assigned to: Alexey Loubyansky (loubyansky) Summary: EJB-SQL conversion bug with OR Initial Comment: Given the following EJBQL : SELECT OBJECT(o) FROM Weight o WHERE ( o.sale.reference = ?1 ) OR ( o.purchase.reference = ?2 ) OR ( o.declaration.reference = ?3 ) with a pk field unid_uoid is converted to the folowing SQL : SELECT t0_o.UNID_UOID FROM WEIGHT t0_o, WEIGHTGROUP t2_o_purchase, WEIGHTGROUP t1_o_sale, WEIGHTGROUP t3_o_declaration WHERE ((t1_o_sale.f_Reference = ?) OR (t2_o_purchase.f_Reference = ?) OR (t3_o_declaration.f_Reference = ?)) AND (t0_o.f_Purchase_UOID=t2_o_purchase.UNID_UOID AND t0_o.f_Sale_UOID=t1_o_sale.UNID_UOID AND t0_o.f_Declaration_UOID=t3_o_declaration.UNID_UOID) The correct SQL would be : SELECT t0_o.UNID_UOID FROM WEIGHT t0_o, WEIGHTGROUP t2_o_purchase, WEIGHTGROUP t1_o_sale, WEIGHTGROUP t3_o_declaration WHERE ( ((t1_o_sale.f_Reference = ?) AND t0_o.f_Sale_UOID=t1_o_sale.UNID_UOID ) OR ((t2_o_purchase.f_Reference = ?) AND t0_o.f_Purchase_UOID=t2_o_purchase.UNID_UOID) OR ((t3_o_declaration.f_Reference = ?) AND t0_o.f_Declaration_UOID=t3_o_declaration.UNID_UOID) ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804968group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804491 ] Unable to add new nodes to cluster
Bugs item #804491, was opened at 2003-09-11 16:56 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to add new nodes to cluster Initial Comment: OS: Solaris 8 JDK: 1.3.1 Logs as attachment We run a cluster of EJB vms with JNDI and EJBs as seperate cluster services. Lately, in production, the cluster gets into a state where each node thinks there are no other nodes in the cluster. The clients are ok with this because the client-side stubs remeber the last cluster configuration and continue to RR over each vm. However, when starting new VMs that want to join the cluster, they do not join. If multiple VMs are started, none of the new VMs cluster with each other. To correct this problem we have to bring down the whole system. Cluster logs with full TRACE debugging are attached. -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 20:36 Message: Logged In: YES user_id=95900 It is not possible to disable it on the server (only on the client). Cheers, sacha -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-12 17:57 Message: Logged In: YES user_id=424902 How do you disable automatic discovery? -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 08:43 Message: Logged In: YES user_id=95900 3.2.1 is old, it is from May, I am pretty sure this has been fixed after, in some of the 3.2.2RCx -- Comment By: Bela Ban (belaban) Date: 2003-09-12 03:14 Message: Logged In: YES user_id=34890 Looks like the AutomaticDiscovery endless loop on HANamingService.stop() is still there. Grep for 'AutomaticDiscovery' and you'll see that 35% of *all* logs statements are these. This sucks a lot of CPU out of the system, maybe the JOINs run into timeouts all the time, that's why we never see each other. Sacha: I thought this was fixed in 3.2.1 ? Bob: can you disable automaticDiscovery for now and test again ? Bela -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-11 20:26 Message: Logged In: YES user_id=424902 Here is jndi-cluster-service.xml ?xml version=1.0 encoding=UTF-8? server classpath codebase=lib archives=jbossha.jar/ !-- -- !-- Cluster Partition: defines cluster -- !-- Based on cluser-services.xml from jboss/server/all/deploy/ -- !-- -- mbean code=org.jboss.ha.framework.server.ClusterPartition name=jboss:service=JndiPartition !-- Name of the partition being built -- attribute name=PartitionNameDefaultPartition/attribute !-- Determine if deadlock detection is enabled -- attribute name=DeadlockDetectionFalse/attribute !-- The JavaGroups protocol configuration -- attribute name=PartitionConfig Config !-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address -- !-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true -- UDP mcast_addr=228.1.2.3 mcast_port=45566 ip_ttl=64 ip_mcast=true mcast_send_buf_size=15 mcast_recv_buf_size=8 ucast_send_buf_size=15 ucast_recv_buf_size=8 loopback=false / PING timeout=2000 num_initial_members=3 up_thread=true down_thread=true / MERGE2 min_interval=5000 max_interval=1 / FD up_thread=true down_thread=true timeout=2500 max_tries=5 shun=true/ VERIFY_SUSPECT timeout=3000 num_msgs=3 up_thread=true down_thread=true / pbcast.STABLE desired_avg_gossip=2 up_thread=true down_thread=true / pbcast.NAKACK gc_lag=50 retransmit_timeout=300,600,1200,2400,4800 up_thread=true down_thread=true / UNICAST timeout=5000 window_size=100 min_threshold=10 down_thread=true / FRAG frag_size=8192 down_thread=true up_thread=true / pbcast.GMS join_timeout=5000 join_retry_timeout=2000 shun=true print_local_addr=true /
[JBoss-dev] [ jboss-Bugs-805136 ] snmp-support.jar seems empty!
Bugs item #805136, was opened at 2003-09-12 18:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=805136group_id=22866
Category: None
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitris Andreadis (andd)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmp-support.jar seems empty!
Initial Comment:
Module console produces snmp-support.jar which is put
in the lib of default and all configurations
The .jar file contains only the manifest entry, although
it's about 96Kb in size.
The build.xml that produces the file (in module console)
is the following:
!-- Create single SNMP archive containing both
JoeSNMP and its log4j appender--
jar destfile=${build.lib}/snmp-support.jar
excludes=META-INF/INDEX.LIST
manifest=${build.etc}/snmp-support.mf
zipfileset
src=${opennms.joesnmp.lib}/joesnmp.jar
include name=**/
exclude name=META-INF/manifest.mf/
/zipfileset
zipfileset
src=${apache.log4j.lib}/snmpTrapAppender.jar
include name=**/
exclude name=META-INF/MANIFEST.MF/
/zipfileset
/jar
Regards
Dimitris
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=805136group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] POP3 support begins in jboss-mail
Hi All, Just a little status blurb.. POP3 support has begun in the jboss-mail module (Mail Services for JBoss). SMTP is coming along well. Eric Daugherty of JES fame has been given readwrite access and has already implemented some bits and pieces of POP support as well as factored out things that are common to SMTP and POP into common code. We even have some folks on the verge of adding TLS (SSL) support to SMTP. If you haven't had a chance, check out the jboss-mail module from CVS and give it a whirl. http://sourceforge.net/cvs/?group_id=22866 Also catch us on the forums where most of the development is happening: http://www.jboss.org/forum.jsp?forum=186 If you've ever wanted to get involved in JBoss or open source in general, this is an excellent place to start. -Andy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] connection listerner lookup has contention
Why are connection listeners for ManagedConnections stored in a shared hashmap within BaseConnectionmanager2? BaseConnectionManager2.getConnectionEventListener(ManagedConnection mc) Why can't the connection listener be stored in the Managed Connection? I'd like to remove this contention. OptimizeIt has this at 32.9% in my little test on a dual CPU machine with 10 threads in contention. Thanks, Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804485 ] JMS message lost on restart
Bugs item #804485, was opened at 2003-09-11 16:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804485group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Udo Schwedt (schwedt) Assigned to: Nobody/Anonymous (nobody) Summary: JMS message lost on restart Initial Comment: Hello all, the following problem occurs on both JBoss 3.2.1 and 3.2.2RC3. I'm running Sun VM 1.4.1_03-b02 on Win2K Pro. With a MDB which listens on a queue using the file based PM, when the server is stopped and started again while JMS are left to consume, exactly one message is lost. To reproduce, set up a simple client and MDB. The client connects to the queue and sends some 50 persistent messages (with an increasing number) to the queue. The MDB's onMessage() method does nothing but to trace the received message and sleep for 10 seconds. When the server is stopped (Ctrl-C) before all messages were consumed, all messages not consumed yet can be found in the persistence directory for the queue, except the message immediately following the latest consumed message (Dead letter queue is empty). If the server is restarted, the remaining persisted messages are processed, but one message is lost. Also see files in attached ZIP archive: - server trace for server 1 (before restart) - server trace for server 2 (after restart) - source for the client - source and XML files MDB - relevant server configuration files In the example files, message no. 16 is lost. BTW: the exception in the server 1 trace: 16:24:59,232 ERROR [JMSContainerInvoker] Exception in JMSCI message listener java.lang.NullPointerException at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:728) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1020) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:636) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:442) at org.jboss.mq.SpySession.run(SpySession.java:294) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:732) at java.lang.Thread.run(Thread.java:536) occurs on shutdown and looks just like the exception mentioned in bug no. 781687 - I thought the bug was already fixed (or didnt the fix make in in 3.2.2RC3)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804485group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [jboss-group] revamping Invocation objects
There is no such compatibility anyway. Or you simply do an Invocation2 and have the server accept both but this will create legacy code that is not very useful. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: vendredi, 12. septembre 2003 00:01 To: Private list for internal JBoss Group discussion Cc: Jboss-Dev Subject: Re: [jboss-group] revamping Invocation objects Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
I agree, compatibility has already been broken between minor 3.2.x versions, so if it allows us to have 20% improvement, I would say: GO! The thinking about compatibility should occur before, not after and requires the establishment of more serious and stable rules (version_id, etc.)s -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: vendredi, 12. septembre 2003 01:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects You guys are talking about a 3.3 proxy talking to a 3.2 server? If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] connection listerner lookup has contention
Just one word... Why can't the connection listener be stored in the Managed Connection? I'd like to remove this contention. OptimizeIt has this at 32.9% in my little test on a dual CPU machine with 10 threads in contention. Wow Marcf --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804667 ] Memory leaks during redeployment
Bugs item #804667, was opened at 2003-09-11 22:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804667group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks during redeployment Initial Comment: JBoss 3.2.1/RC1/RC2 suffers from memory leaks during redeployment process. In jboss-user list I was told that this is a known issue the team is working on. Just wanted to keep track of the bug... Please point me to the bug # if the one is already submitted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804667group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Shutdown failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === 02:26:14,944 WARN [NamingContext] Failed to connect to localhost:1099 javax.naming.CommunicationException: Failed to connect to server localhost:1099. Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099. Root exception is java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:434) at java.net.Socket.connect(Socket.java:384) at java.net.Socket.init(Socket.java:291) at java.net.Socket.init(Socket.java:199) at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:69) at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:62) at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:186) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.jboss.Shutdown.main(Shutdown.java:180) Exception in thread main javax.naming.CommunicationException: Receive timed out. Root exception is java.net.SocketTimeoutException: Receive timed out at java.net.PlainDatagramSocketImpl.receive(Native Method) at java.net.DatagramSocket.receive(DatagramSocket.java:680) at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1093) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1192) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.jboss.Shutdown.main(Shutdown.java:180) JBOSS SHUTDOWN FAILED ===Sat Sep 13 02:26:20 BST 2003 ===Linux nog 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown ===java version 1.4.1_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01) Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: 46 % ( 327 / 704 ) - skipping class too much
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 704 Successful tests: 327 Errors:324 Failures: 53 [time of test: 2003-09-12.23-17 GMT] [java.version: 1.4.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_05-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-20.7] Useful resources: - http://jboss.kimptoc.net/linux1/logtests/testresults/reports/html//2003-09-12.23-17 for the junit report of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: Test:AOPUnitTestCase Type:error Exception: java.lang.reflect.InvocationTargetException Message: - Suite: Test:RemotingUnitTestCase Type:error Exception: java.lang.reflect.InvocationTargetException Message: - Suite: Test:SecurityUnitTestCase Type:error Exception: java.lang.reflect.InvocationTargetException Message: - Suite: Test:SimpleBeanUnitTestCase Type:error Exception: java.lang.reflect.InvocationTargetException Message: - Suite: Test:TxLockUnitTestCase Type:error Exception: java.lang.reflect.InvocationTargetException Message: - Suite: Test:TxUnitTestCase Type:error Exception: java.lang.reflect.InvocationTargetException Message: ===Sat Sep 13 02:27:02 BST 2003 ===Linux nog 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown ===java version 1.4.1_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01) Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804491 ] Unable to add new nodes to cluster
Bugs item #804491, was opened at 2003-09-11 14:56 Message generated for change (Comment added) made by bcotton969 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to add new nodes to cluster Initial Comment: OS: Solaris 8 JDK: 1.3.1 Logs as attachment We run a cluster of EJB vms with JNDI and EJBs as seperate cluster services. Lately, in production, the cluster gets into a state where each node thinks there are no other nodes in the cluster. The clients are ok with this because the client-side stubs remeber the last cluster configuration and continue to RR over each vm. However, when starting new VMs that want to join the cluster, they do not join. If multiple VMs are started, none of the new VMs cluster with each other. To correct this problem we have to bring down the whole system. Cluster logs with full TRACE debugging are attached. -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-12 15:57 Message: Logged In: YES user_id=424902 How do you disable automatic discovery? -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 06:43 Message: Logged In: YES user_id=95900 3.2.1 is old, it is from May, I am pretty sure this has been fixed after, in some of the 3.2.2RCx -- Comment By: Bela Ban (belaban) Date: 2003-09-12 01:14 Message: Logged In: YES user_id=34890 Looks like the AutomaticDiscovery endless loop on HANamingService.stop() is still there. Grep for 'AutomaticDiscovery' and you'll see that 35% of *all* logs statements are these. This sucks a lot of CPU out of the system, maybe the JOINs run into timeouts all the time, that's why we never see each other. Sacha: I thought this was fixed in 3.2.1 ? Bob: can you disable automaticDiscovery for now and test again ? Bela -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-11 18:26 Message: Logged In: YES user_id=424902 Here is jndi-cluster-service.xml ?xml version=1.0 encoding=UTF-8? server classpath codebase=lib archives=jbossha.jar/ !-- -- !-- Cluster Partition: defines cluster -- !-- Based on cluser-services.xml from jboss/server/all/deploy/ -- !-- -- mbean code=org.jboss.ha.framework.server.ClusterPartition name=jboss:service=JndiPartition !-- Name of the partition being built -- attribute name=PartitionNameDefaultPartition/attribute !-- Determine if deadlock detection is enabled -- attribute name=DeadlockDetectionFalse/attribute !-- The JavaGroups protocol configuration -- attribute name=PartitionConfig Config !-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address -- !-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true -- UDP mcast_addr=228.1.2.3 mcast_port=45566 ip_ttl=64 ip_mcast=true mcast_send_buf_size=15 mcast_recv_buf_size=8 ucast_send_buf_size=15 ucast_recv_buf_size=8 loopback=false / PING timeout=2000 num_initial_members=3 up_thread=true down_thread=true / MERGE2 min_interval=5000 max_interval=1 / FD up_thread=true down_thread=true timeout=2500 max_tries=5 shun=true/ VERIFY_SUSPECT timeout=3000 num_msgs=3 up_thread=true down_thread=true / pbcast.STABLE desired_avg_gossip=2 up_thread=true down_thread=true / pbcast.NAKACK gc_lag=50 retransmit_timeout=300,600,1200,2400,4800 up_thread=true down_thread=true / UNICAST timeout=5000 window_size=100 min_threshold=10 down_thread=true / FRAG frag_size=8192 down_thread=true up_thread=true / pbcast.GMS join_timeout=5000 join_retry_timeout=2000 shun=true print_local_addr=true / pbcast.STATE_TRANSFER up_thread=true down_thread=true / /Config /attribute attribute name=PartitionNameJndi/attribute /mbean !-- -- !-- HA JNDI
[JBoss-dev] EURO BOOT CAMP Amsterdam NEW DATES
So someone reminded me that in europe people don't like to take time off their hollidays or weekends to go to a training. How could I forget? Silly me. So we moved the dates for the amsterdam bootcamp from the weekend Oct 11-12 to OCT 13-14. If you have already registered we will be contacting you individually. The bootcamp will feature all the european crew and some of the US as well, it is going to be a good event, The new dates are MONDAY and TUESDAY OCT 13-14. http://www.jbossgroup.com/index.html?module=htmlop=userdisplayid=servi ces/training/bootcamp marcf x Marc Fleury, Ph.D Founder JBoss Group, LLC x --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804491 ] Unable to add new nodes to cluster
Bugs item #804491, was opened at 2003-09-11 14:56 Message generated for change (Comment added) made by bcotton969 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to add new nodes to cluster Initial Comment: OS: Solaris 8 JDK: 1.3.1 Logs as attachment We run a cluster of EJB vms with JNDI and EJBs as seperate cluster services. Lately, in production, the cluster gets into a state where each node thinks there are no other nodes in the cluster. The clients are ok with this because the client-side stubs remeber the last cluster configuration and continue to RR over each vm. However, when starting new VMs that want to join the cluster, they do not join. If multiple VMs are started, none of the new VMs cluster with each other. To correct this problem we have to bring down the whole system. Cluster logs with full TRACE debugging are attached. -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-11 18:26 Message: Logged In: YES user_id=424902 Here is jndi-cluster-service.xml ?xml version=1.0 encoding=UTF-8? server classpath codebase=lib archives=jbossha.jar/ !-- -- !-- Cluster Partition: defines cluster -- !-- Based on cluser-services.xml from jboss/server/all/deploy/ -- !-- -- mbean code=org.jboss.ha.framework.server.ClusterPartition name=jboss:service=JndiPartition !-- Name of the partition being built -- attribute name=PartitionNameDefaultPartition/attribute !-- Determine if deadlock detection is enabled -- attribute name=DeadlockDetectionFalse/attribute !-- The JavaGroups protocol configuration -- attribute name=PartitionConfig Config !-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address -- !-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true -- UDP mcast_addr=228.1.2.3 mcast_port=45566 ip_ttl=64 ip_mcast=true mcast_send_buf_size=15 mcast_recv_buf_size=8 ucast_send_buf_size=15 ucast_recv_buf_size=8 loopback=false / PING timeout=2000 num_initial_members=3 up_thread=true down_thread=true / MERGE2 min_interval=5000 max_interval=1 / FD up_thread=true down_thread=true timeout=2500 max_tries=5 shun=true/ VERIFY_SUSPECT timeout=3000 num_msgs=3 up_thread=true down_thread=true / pbcast.STABLE desired_avg_gossip=2 up_thread=true down_thread=true / pbcast.NAKACK gc_lag=50 retransmit_timeout=300,600,1200,2400,4800 up_thread=true down_thread=true / UNICAST timeout=5000 window_size=100 min_threshold=10 down_thread=true / FRAG frag_size=8192 down_thread=true up_thread=true / pbcast.GMS join_timeout=5000 join_retry_timeout=2000 shun=true print_local_addr=true / pbcast.STATE_TRANSFER up_thread=true down_thread=true / /Config /attribute attribute name=PartitionNameJndi/attribute /mbean !-- -- !-- HA JNDI -- !-- -- mbean code=org.jboss.ha.jndi.HANamingService name=jboss:service=HAJNDI dependsjboss:service=JndiPartition/depends !-- Name of the partition to which the service is linked -- attribute name=PartitionNameJndi/attribute !-- RmiPort to be used by the HA-JNDI service once bound. 0 = auto. -- attribute name=RmiPort0/attribute !-- Port on which the HA-JNDI stub is made available -- attribute name=Port1098/attribute !-- Backlog to be used for client-server RMI invocations during JNDI queries -- attribute name=Backlog50/attribute !-- Client socket factory to be used for client-server RMI invocations during JNDI queries -- !--attribute name=ClientSocketFactorycustom/attribute-- !-- Server socket factory to be used for client-server RMI invocations during JNDI queries -- !--attribute
Re: [JBoss-dev] compile error in today's snapshot from Sun's 1.3.1_07
Sorry, my bad Adrian Brock wrote: Fixed, it now uses org.jboss.util.NestedRuntimeException Regards, Adrian On Thu, 2003-09-11 at 16:26, Rod Burgett wrote: I'm trying to compile the 3.2 snapshot with Sun's 1.3.1_07 jdk. It seems that org.jboss.tm.TxUtils.java is trying to use a RuntimeException constructor with Throwable parameter. But that ctor is only available in 1.4. Has support for 1.3.1 been abandoned, or is this a bug? It can be coaxed through the compiler by changing 'new RuntimeException(ignored)' to 'new RuntimeException(ignored.toString())' in 6 places. Is there a better solution involving a JBoss wrapper exception? Rod Burgett webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only) It's all just 0s 1s - the trick is getting them lined up in the proper order --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-804491 ] Unable to add new nodes to cluster
Bugs item #804491, was opened at 2003-09-11 16:56 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to add new nodes to cluster Initial Comment: OS: Solaris 8 JDK: 1.3.1 Logs as attachment We run a cluster of EJB vms with JNDI and EJBs as seperate cluster services. Lately, in production, the cluster gets into a state where each node thinks there are no other nodes in the cluster. The clients are ok with this because the client-side stubs remeber the last cluster configuration and continue to RR over each vm. However, when starting new VMs that want to join the cluster, they do not join. If multiple VMs are started, none of the new VMs cluster with each other. To correct this problem we have to bring down the whole system. Cluster logs with full TRACE debugging are attached. -- Comment By: Sacha Labourey (slaboure) Date: 2003-09-12 08:43 Message: Logged In: YES user_id=95900 3.2.1 is old, it is from May, I am pretty sure this has been fixed after, in some of the 3.2.2RCx -- Comment By: Bela Ban (belaban) Date: 2003-09-12 03:14 Message: Logged In: YES user_id=34890 Looks like the AutomaticDiscovery endless loop on HANamingService.stop() is still there. Grep for 'AutomaticDiscovery' and you'll see that 35% of *all* logs statements are these. This sucks a lot of CPU out of the system, maybe the JOINs run into timeouts all the time, that's why we never see each other. Sacha: I thought this was fixed in 3.2.1 ? Bob: can you disable automaticDiscovery for now and test again ? Bela -- Comment By: Bob Cotton (bcotton969) Date: 2003-09-11 20:26 Message: Logged In: YES user_id=424902 Here is jndi-cluster-service.xml ?xml version=1.0 encoding=UTF-8? server classpath codebase=lib archives=jbossha.jar/ !-- -- !-- Cluster Partition: defines cluster -- !-- Based on cluser-services.xml from jboss/server/all/deploy/ -- !-- -- mbean code=org.jboss.ha.framework.server.ClusterPartition name=jboss:service=JndiPartition !-- Name of the partition being built -- attribute name=PartitionNameDefaultPartition/attribute !-- Determine if deadlock detection is enabled -- attribute name=DeadlockDetectionFalse/attribute !-- The JavaGroups protocol configuration -- attribute name=PartitionConfig Config !-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address -- !-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true -- UDP mcast_addr=228.1.2.3 mcast_port=45566 ip_ttl=64 ip_mcast=true mcast_send_buf_size=15 mcast_recv_buf_size=8 ucast_send_buf_size=15 ucast_recv_buf_size=8 loopback=false / PING timeout=2000 num_initial_members=3 up_thread=true down_thread=true / MERGE2 min_interval=5000 max_interval=1 / FD up_thread=true down_thread=true timeout=2500 max_tries=5 shun=true/ VERIFY_SUSPECT timeout=3000 num_msgs=3 up_thread=true down_thread=true / pbcast.STABLE desired_avg_gossip=2 up_thread=true down_thread=true / pbcast.NAKACK gc_lag=50 retransmit_timeout=300,600,1200,2400,4800 up_thread=true down_thread=true / UNICAST timeout=5000 window_size=100 min_threshold=10 down_thread=true / FRAG frag_size=8192 down_thread=true up_thread=true / pbcast.GMS join_timeout=5000 join_retry_timeout=2000 shun=true print_local_addr=true / pbcast.STATE_TRANSFER up_thread=true down_thread=true / /Config /attribute attribute name=PartitionNameJndi/attribute /mbean !-- -- !-- HA JNDI -- !-- -- mbean code=org.jboss.ha.jndi.HANamingService
