[JBoss-dev] [ jboss-Bugs-796177 ] JBoss failes to remove lock on CMP beans w/o transaction
Bugs item #796177, was opened at 2003-08-27 14:00 Message generated for change (Comment added) made by patriot1burke You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=796177group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Jari Juslin (zds0) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss failes to remove lock on CMP beans w/o transaction Initial Comment: JBoss 3.2.1, Red Had Linux 6.2, Sun JVM 1.4.2 for Linux I have EJB 2.0 CMP entity bean, that was accessed both with and without transaction. When two threads performed operations on it's fields at the same time, it sometimes ended up throwing exception like the one below. The wort part is that JBoss was not able to recover from this: subsequent calls to that bean always threw the same exception over and over again. This effectively put our system out of operation, since no retry could get through and bean clients were stuck. We now added transactions to all the beans participating to these operations, but this is still something that should be corrected. AFAIK the EJB 2.0 spec strongly recommends to always use transactions with CMP entity beans, and lets engines not to support accessing CMP beans w/o transaction, but if JBoss chooses to do so it should not let user deploy beans it can't handle correctly. 2003-08-24 03:54:38,689 WARN [org.jboss.tm.TransactionImpl] Transaction TransactionImpl:XidImpl [FormatId=257, GlobalId=www.matchem.com//540079, BranchQual=] timed out. status=STATUS_ACTIVE 2003-08-24 03:54:38,690 WARN [org.jboss.tm.TransactionImpl] Lock contention, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=www.matchem.com//540079, BranchQual=] 2003-08-24 03:54:38,691 ERROR [org.jboss.ejb.BeanLock] PoolThread-10Saw rolled back tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=www.matchem.com//540079, BranchQual=] waiting for txLock 2003-08-24 03:54:38,691 ERROR [org.jboss.ejb.BeanLock] removing bean lock and it has tx set! QPL bean=MITVCharacter id=[.158285.] tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=www.matchem.com//540019, BranchQual=] synched=null timeout=5000 queue=[] 2003-08-24 03:54:38,692 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException, causedBy: java.lang.IllegalStateException: removing bean lock and it has tx set! at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.removeRef(QueuedPessimisticEJBLock.java:430) at org.jboss.ejb.BeanLockManager.removeLockRef(BeanLockManager.java:107) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:106) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:53) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:273) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:117) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:483) at org.jboss.ejb.Container.invoke(Container.java:674) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:353) at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38) at $Proxy170.getRealName(Unknown Source) at com.matchem.mitv.common.tvchat.TVChatShowComponentBean.getNewChatEntries(TVChatShowComponentBean.java:273) at sun.reflect.GeneratedMethodAccessor63.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:878) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:117) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:271) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at
[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 (Tracker Item Submitted) made by Item Submitter 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_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 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 15:02 Message: Logged In: YES user_id=424902 Logs too big to attach. Logs can be accessed at: http://clubcotton.homeip.net/jboss/synxis-cluster-logs.zip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_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] compile error in today's snapshot from Sun's 1.3.1_07
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
Re: [JBoss-dev] compile error in today's snapshot from Sun's 1.3.1_07
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 -- Adrian Brock Director of Support Back Office 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] 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. --- 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
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
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 --- 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
On Fri, 2003-09-12 at 00:27, marc fleury wrote: You guys are talking about a 3.3 proxy talking to a 3.2 server? 3.2.1 proxy talking to 3.2.2 server or vice versa. 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? Yes and the serialization of the Invocation object. 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 --- 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 -- Adrian Brock Director of Support Back Office 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 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:17
Message:
Logged In: YES
user_id=424902
This is jboss 3.2.1 with a new javagroups.jar that I
received from you.
Decompile of org.javagroups.Version yields:
public static String version = 2.0.8;
public static byte[] version_id = { 48, 50, 48, 56 };
public static String cvs
= $Id: Version.java,v 1.19 2003/04/04 22:54:12
belaban Exp $;
--
Comment By: Sacha Labourey (slaboure)
Date: 2003-09-11 15:20
Message:
Logged In: YES
user_id=95900
Which specific JBoss release? JavaGroups bugs have been
fixed in recent jboss release that fix that kind of merge
issues, you may want to try it.
--
Comment By: Bob Cotton (bcotton969)
Date: 2003-09-11 15:02
Message:
Logged In: YES
user_id=424902
Logs too big to attach. Logs can be accessed at:
http://clubcotton.homeip.net/jboss/synxis-cluster-logs.zip
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=804491group_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 07:56 Message generated for change (Comment added) made by belaban 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: Bela Ban (belaban) Date: 2003-09-11 18: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 11: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
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Shutdown failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === 02:07:07,511 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 ===Fri Sep 12 02:07:12 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: 47 % ( 309 / 657 ) - 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: 657 Successful tests: 309 Errors:299 Failures: 49 [time of test: 2003-09-11.23-16 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-11.23-16 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: ===Fri Sep 12 02:07:50 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] Organizasyonlarimizda Calisacak Gencler Ariyoruz
BÝZÝMLE ÇALIÞMAK ÝSTERMÝSÝNÝZ ? DALTONS KÝMDÝR; 1996 yýlýnda Galatasaray Lisesi'nde okurken, gençlere yönelik organizasyon sektöründeki arzýn talebi karþýlamadýðýný farkýna varan 4 genç giriþimcinin yarattýklarý oluþum, ilk olarak kendi çevrelerindeki gençler için düzenledikleri Uludað ve Bodrum turlarý ile iþe baþladý. 4 kiþi olmalarý sebebiyle Daltonlardan esinlenerek kendilerine DALTONS ismini uygun gördüler. Ucuz ama kaliteli hizmet anlayýþýyla, gençlere yönelik birçok organizasyon düzenlerken , tamamý öðrencilerden oluþan tanýtým ve daðýtým ekiplerinin de geliþmesiyle DALTONS , amatör ruhunu koruyarak profesyonelliðe ilk adýmlarýný attý. Müþterilerine gösterdikleri samimi tavýrlarý, organizasyonlarýn sorunsuz ve çok eðlenceli geçmesi ile eðlence turizmi ve gençlik organizasyonlarýnýn en tercih edilen firmasý haline geldiler. Ýstanbul çapýnda yürüttükleri tanýtým çalýþmalarýný, Ankara ve Ýzmir e de yayarak geliþimlerini sürdürdüler.7 yýl gibi kýsa bir sürede büyük bir ivme ile büyüyerek 1200 kiþiyi aþan gruplara varan kitleleri peþinden sürükleyen organizasyonlara imzalarýný attýlar. ÇALIÞMA ÞEKLÝ ; DALTONS'un satýþ aðý;Lise ve Üniversitelerdeki öðrencilerden oluþmaktadýr. Organizasyonlarýný (Popüler bir yere tur, party vb...) tanýtma þekli ise ;bu satýþ aðýndaki gençlerin, okullarýna , organizasyonun flyerlarýný ve posterlerini asýp, kendisine yöneltilebilecek sorulara cevap vermesi ve çevresine organizasyonu anlatarak, haber vererek kulaktan kulaða yayýlmasýný saðlamak olarak açýklanabilir. Bu noktada en önemli þeylerden birkaçý , geniþ bir çevrenizin olmasý , okul yönetimiyle iyi iliþkiler içerisinde olmanýz ve giriþken-sosyal bir insan olmanýz olarak sýralanabilir. Tanýtým yapýldýktan sonra rezervasyonlar alýnýr ve bu rezervasyonlar merkez ofise bildirilerek satýþ tamamlanmýþ olur. Satýþtan sonra organizasyon sýrasýnda görev almak ; ne kadar satýþ yapýldýðýna ve gereksinime göre ayarlanmaktadýr. BÝZÝMLE ÇALIÞMAK ÝSTERMÝSÝNÝZ ? Daltons'un gençlere yönelik turlarýnda ve organizasyonlarýnda görev almak ister misiniz? Liselerde ve Üniversitelerde tanýtýmýmýzda ve organizasyonlarýmýzda yer alacak gençler arýyoruz 16 yaþýndan büyükseniz Geniþ bir çevreniz olduðunu düþünüyorsanýz, Ýkna kabiliyetinize güveniyorsanýz, Sosyal ve giriþken bir insansanýz, Süreklilik ve Ciddiyetle çalýþabileceðinize inanýyorsanýz, Kendinize ,Okulunuza , Ýþinize vakit ayýrarak ; Çevrenizi geliþtirerek ve eðlenerek çalýþma fýrsatý için [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] adresine kendinizi tanýtan kýsa bir yazý ve mümkünse bir fotoðrafýnýzý ekleyip edip yollayýn. DERYA ÖZYUVALI DLT TOUR ORG. TEL : (216) 355 21 21 FAX : (216) 355 31 31 BAÐDAT CAD. NO:389/8 ÞAÞKINBAKKAL/ISTANBUL ARADIÐIMIZ ÖNCELÝKLÝ OKULLAR : · ISTANBUL UNÝVERSÝTELER : BAHÇEÞEHÝR BEYKENT BÝLGÝ BOÐAZÝÇÝ DOÐUÞ FATÝH UNÝ. GSÜ HALÝÇ IÞIK ÝSTANBUL ÝTO ÝTÜ KADÝR HAS KOÇ KÜLTÜR MALTEPE MARMARA MÝMAR SÝNAN SABANCI YEDÝTEPE YILDIZ · ANKARA UNÝVERSÝTELER : ANKARA UNÝ. BAÞKENT BÝLKENT GAZÝ HACETTEPE ODTÜ · ÝZMÝR UNÝVERSÝTELER : DOKUZ EYLÜL EGE ÝZMÝR EKONOMÝ · ESKÝÞEHÝR UNÝVERSÝTELER : ANADOLU UNÝ. · KOCAELÝ UNÝVERSÝTELER: KOCAELÝ · BURSA UNÝVERSÝTELER : ULUDAÐ UNÝ. · ISTANBUL LÝSELER : ALMAN LÝSESÝ AVUSTURYA NDS GALATASARAY ROBERT ÝTALYAN ÝSTANBUL ST. BENOÝT ST. JOSEPH ST. PULCHERÝE ST. MÝCHEL IÞIK LÝSESÝ KOÇ LÝSESÝ ÜSKÜDAR AMERÝKAN PÝERRE LOTÝ EYÜBOÐLU KOLEJÝ BRITISH SCHOOL ÝSTEK ACIBADEM ÝSTEK KEMAL ATATÜRK SEMÝHA ÞAKÝR YÜZYIL IÞIL ATA KOLEJÝ KADIKÖY ANADOLU MEF ÝSTEK BELDE ÖZEL KALAMIÞ ÖZEL IRMAK BÝLFEN ANABÝLÝM ÝSTEK BALMUMCU ANAKENT KOLEJÝ AHMET ÞÝMÞEK BÝLGÝ LÝSESÝ · ANKARA LÝSELER : TEVFÝK FÝKRET ANKARA · ÝZMÝR LÝSELER : ÝZMÝR AMERÝKAN ÝZMÝR ST. JOSEPH · MERSÝN LÝSELER : TARSUS AMERÝKAN --- 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
