[JBoss-dev] RE: Clustering tasks
Can Sacha or somebody explain what the various http replication schemes are ? >Sacha: - sexy httpsession replication schemes Ivelin --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Hibernate deployer?
I'd be curious to hear what Gavin thinks about this. Is he on this list? Ivelin --- Adrian Brock <[EMAIL PROTECTED]> wrote: > Hi Ivelin, > > I don't know that pooling is required for a > hibernate session. > > But one big advantage to j2ee is you can reuse > the same code with different deployment descriptors > to get different quality of service. > > i.e. You can use the same bean inside outside a > transaction depending upon how you configure the > resources. > Maybe the hibernate factory is enough in this case? > > Regards, > Adrian > > On Sun, 2003-12-21 at 17:17, Ivelin Ivanov wrote: > > Pardon my negligence with JCA, but I think that > the > > added benefit of the proposed mechanism releases > the > > developer from the responsibility to manually > worry > > about closing sessions. Reduces the need for these > > pesky try/catch/finally. > > > > Since the Hibernate session is on top of a > DataSource, > > which is hopefully pooled, there is no need to > pool > > sessions. > > > > > > Does this make sense, or I missed your point? > > > > Ivelin > > > > > > --- Adrian Brock <[EMAIL PROTECTED]> wrote: > > > On Sat, 2003-12-20 at 13:24, Ivelin Ivanov > wrote: > > > > Related to this, I just bundled a proposed > > > addition to > > > > the Hibernate/JBoss integration. > > > > Gavin seemed to approve the design pattern. > > > Hopefully > > > > my implementation is acceptable. > > > > > > > > http://hibernate.org/66.82.html > > > > > > > > Let me know what you think. > > > > > > This looks like a cutdown version of what the > jca > > > does in local > transaction > > > mode, > > > except without any pooling of sessions. > > > > > > Doesn't Hibernate have a resource adapter > already? > > > > > > I thought the point of the hibernate deployer > was > > > to deploy the mappings? > > > > > > Regards, > > > Adrian > > > > > > > > > > > Ivelin > > > > > > > > > > > > --- Andrew Oliver <[EMAIL PROTECTED]> wrote: > > > > > I'm working on getting up to speed with > > > Hibernate. > > > > > I started following > > > > > these (http://hibernate.org/66.html) > > > instructions > > > > > but I'd rather have only 1 > > > > > instance of Hibernate for all of my > hibernated > > > > > stuff. How far along is the > > > > > deployer? I'm running the HEAD and the SAR > > > seems > > > > > happy. I'm willing to > > > > > help the deployer along if you point me to > it. > > > > > > > > > > Thanks, > > > > > > > > > > Andy > > > > > > > > > > > > > > > cc: Gavin as I don't know if he's watching > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > This SF.net email is sponsored by: IBM Linux > > > > > Tutorials. > > > > > Become an expert in LINUX or just sharpen > your > > > > > skills. Sign up for IBM's > > > > > Free Linux Tutorials. Learn everything from > the > > > > > bash shell to sys admin. > > > > > Click now! > > > > > > > > > > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > > > ___ > > > > > JBoss-Development mailing list > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > > > > > > > > --- > > > > This SF.net email is sponsored by: IBM Linux > > > Tutorials. > > > > Become an expert in LINUX or just sharpen your > > > skills. Sign up for IBM's > > > > Free Linux Tutorials. Learn everything from > the > > > bash shell to sys admin. > > > > Click now! > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > > ___ > > > > 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: IBM Linux > > > Tutorials. > > > Become an expert in LINUX or just sharpen your > > > skills. Sign up for IBM's > > > Free Linux Tutorials. Learn everything from the > > > bash shell to sys admin. > > > Click now! > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > ___ > > > JBoss-Development mailing list > > > [EMAIL PROTECTED] > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > --- > > This SF.net email is sponsored by: IBM Linux > Tutorials. > > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > > Click now! > http://ad
[JBoss-dev] JBoss Test Results: 94 % ( 1445 / 1524 ) - come on - pull your finger out. JBoss (HEAD/linux1/1.4.1_05) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Mon Dec 22 02:14:43 GMT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1524 Successful tests: 1445 Errors:63 Failures: 16 [time of test: 2003-12-22.00-42 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/1.4.1_05/logtests/testresults/reports/html//2003-12-22.00-42 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: LocalUnitTestCase Test:testSetup Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: /home/jbossci/jbossci2/jboss-head-test/build/output/testbuild/server/all/tmp/sessions/test/TreeCacheAopTester-dohtn8d4-16/dohtn9qc-19.ser (No such file or directory) - Suite: TxConcurrentUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: ScopingUnitTestCase Test:testSingletons Type:failure Exception: junit.framework.AssertionFailedError Message: checkVersion(V2) is true - Suite: AppClientUnitTestCase Test:testENC Type:error Exception: javax.naming.NameNotFoundException Message: test-client not bound - Suite: AppClientUnitTestCase Test:testEjbs Type:error Exception: javax.naming.NameNotFoundException Message: test-client not bound - Suite: ReadonlyUnitTestCase Test:testSetUp Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Column not found: ID in statement [INSERT INTO Publisher (id, name) VALUES (1,'O''Reilly & Associates')] === Mon Dec 22 02:14:43 GMT 2003 === Linux nog.kimptoc.net 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown === java -version 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: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Test Results: 94 % ( 1465 / 1548 ) - come on - pull your finger out. JBoss (HEAD/winxp/1.4.1_05) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Mon Dec 22 01:44:16 GMTST 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1548 Successful tests: 1465 Errors:65 Failures: 18 [time of test: 2003-12-22.00-52 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: Windows XP] [os.arch: x86] [os.version: 5.1] Useful resources: - http://jboss.kimptoc.net/winxp/1.4.1_05/logtests/testresults/reports/html//2003-12-22.00-52 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: LocalUnitTestCase Test:testSetup Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: D:\jboss\jboss-head-test\build\output\testbuild\server\all\tmp\sessions\test\TreeCacheAopTester-dohtnj52-16\dohtnkjf-19.ser (The system cannot find the file specified) - Suite: TxConcurrentUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: SyncTxUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: ScopingUnitTestCase Test:testSingletons Type:failure Exception: junit.framework.AssertionFailedError Message: checkVersion(V2) is true - Suite: AppClientUnitTestCase Test:testENC Type:error Exception: javax.naming.NameNotFoundException Message: test-client not bound - Suite: AppClientUnitTestCase Test:testEjbs Type:error Exception: javax.naming.NameNotFoundException Message: test-client not bound === Mon Dec 22 01:44:17 GMTST 2003 === CYGWIN_NT-5.1 quarks2 1.5.4(0.94/3/2) 2003-09-12 23:08 i686 unknown unknown Cygwin === java -version 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: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Alprazolam.m Vicodin.n Valium.m Xanax.x fqvumgbc k cmlzx
Many Specials running this week THE RE.AL THING not like the other sites that imitate these products. No hidd.en char.ges - Fast Delivery Vic.odin Val.ium Xan.ax Via.gra Diaz.epam Alpra.zolam So.ma Fior.icet Amb.ien Stil.nox Ult.ram Zo.loft Clon.azepam At.ivan Tr.amadol Xeni.cal Cele.brex Vi.oxx Pro.zac Bus.par Much M.ore http://www.nowbetterthis.biz/l/105/index.htm If you have recieved this in error please use http://www.nowbetterthis.biz/byee.html b blqk cqveuwf i yzaroj hjrectolxk
[JBoss-dev] Re: CNIOQOKT, the mountains turned
Banned CD! Government don't want me to sell it. See Now & sensuous burgundy plumbago defraud criterion almighty armful keel accentual mole vicar cdc arkansas durkin chile rensselaer mercy convalesce anagram curl danbury distributive archbishop adjutant midshipman phipps boomerang apices breadroot depose nanking gummy gall inference lurid bashaw peep retardation mcneil kingsley ache mo stable caliph torso tuscany modest deliver denumerable opal watkins berkshire postage beady mot catcall committeewoman calligraphy fried cassock
Re: [JBoss-dev] Re: HA JMS - singleton load balancing policy
The current 3.2 invokers don't have any notion of client callback. You could make it work if you could guarantee an MBeanServer on the clients (which you cannot). Otherwise they would need to be modified to target something other than an ObjectName on the MBus. The remoting framework has client callbacks but it is not transparent (at least last time I looked at it). The subsystem has to know what client callbacks are involved. This is very unclean since it depends upon what sort of callback the transport supports (e.g. two-way socket stream like UIL2, two sockets like OIL, RMI or whether the client has to do polling). IMHO, the client callback should be part of the transport layer which knows best how to optimize it. Ideally it should be more transparent like RMI where something that implements java.rmi.Remote is replaced with its remote stub as it passes through the transport layer. Regards, Adrian On Sun, 2003-12-21 at 17:05, Ivelin Ivanov wrote: > Yes, this is how it works now. > The client side of the HAIL uses the singleton > notifications, which in turn use the DRM. > The question is how to implement the client stub so > that it does not have to be part of the cluster. > > The smart RMI stubs take care of communicating with > the back end to receive regular snapshots of the > cluster view. There has to be additinal info about the > current singleton server. As Scott mentioned this can > be probably done as an extension to one of the load > balncing policies. > > However UIL2 does not use the smart RMI stubs. How to > merge them? Just use the RMI stuff for HAIL and don't > worry about UIL2 for now? > > Is the existing remoting at a stage that can replace > UIL2 without any loss of benefits ? I am not familiar > with it yet. > > Ivelin > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > The DistributedReplicantManager should be able to > > organize separate > > endpoints. HAIL or any other IL should interface > > with it. > > > > Bill > > > > Ivelin Ivanov wrote: > > > > > Ok, that is what I thought. > > > Let's see if this can be an easy fix. > > > Seems like UIL2 doesn't leverage the smart RMI > > stubs. > > > Any suggestions how to attack this? Have UIL2 use > > > smart RMI stubs somehow, write a completely > > different > > > IL based on the smart RMI stubs or reuse OIL. > > > > > > Currently the HAIL client stub is listening for > > > changes in the cluster topology and cancels the > > > connection when the singleton moves. > > > > > > > > > Ivelin > > > > > > --- Scott M Stark <[EMAIL PROTECTED]> wrote: > > > > > >>Its a variation of the FirstAvailable load > > balancing > > >>policy that > > >>chooses the singleton rather than one of the > > cluster > > >>nodes. > > >> > > >>-- > > >> > > >>Scott Stark > > >>Chief Technology Officer > > >>JBoss Group, LLC > > >> > > >> > > >>Ivelin Ivanov wrote: > > >> > > >> > > >>>An interesting problem came up related to HA JMS. > > >>>There is a need for a remoting mechanism that can > > >> > > >>not > > >> > > >>>only keep a current list of the cluster nodes, > > but > > >>>also know which one is the singleton node for a > > >>>particular service. > > >>> > > >>>Is this something that should be added to the > > >> > > >>roadmap > > >> > > >>>under remoting? Would it be implemented as a kind > > >> > > >>of > > >> > > >>>load-balancing strategy or some other way? > > >>> > > >>>Ivelin > > >>> > > >> > > >> > > >> > > >> > > > > > > --- > > > > > >>This SF.net email is sponsored by: IBM Linux > > >>Tutorials. > > >>Become an expert in LINUX or just sharpen your > > >>skills. Sign up for IBM's > > >>Free Linux Tutorials. Learn everything from the > > >>bash shell to sys admin. > > >>Click now! > > >> > > > > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > > >>___ > > >>JBoss-Development mailing list > > >>[EMAIL PROTECTED] > > >> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: IBM Linux > > Tutorials. > > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > ___ > > > 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: IBM Linux > > Tutorials. > >
Re: [JBoss-dev] Hibernate deployer?
Hi Ivelin, I don't know that pooling is required for a hibernate session. But one big advantage to j2ee is you can reuse the same code with different deployment descriptors to get different quality of service. i.e. You can use the same bean inside outside a transaction depending upon how you configure the resources. Maybe the hibernate factory is enough in this case? Regards, Adrian On Sun, 2003-12-21 at 17:17, Ivelin Ivanov wrote: > Pardon my negligence with JCA, but I think that the > added benefit of the proposed mechanism releases the > developer from the responsibility to manually worry > about closing sessions. Reduces the need for these > pesky try/catch/finally. > > Since the Hibernate session is on top of a DataSource, > which is hopefully pooled, there is no need to pool > sessions. > > > Does this make sense, or I missed your point? > > Ivelin > > > --- Adrian Brock <[EMAIL PROTECTED]> wrote: > > On Sat, 2003-12-20 at 13:24, Ivelin Ivanov wrote: > > > Related to this, I just bundled a proposed > > addition to > > > the Hibernate/JBoss integration. > > > Gavin seemed to approve the design pattern. > > Hopefully > > > my implementation is acceptable. > > > > > > http://hibernate.org/66.82.html > > > > > > Let me know what you think. > > > > This looks like a cutdown version of what the jca > > does in local transaction > > mode, > > except without any pooling of sessions. > > > > Doesn't Hibernate have a resource adapter already? > > > > I thought the point of the hibernate deployer was > > to deploy the mappings? > > > > Regards, > > Adrian > > > > > > > > Ivelin > > > > > > > > > --- Andrew Oliver <[EMAIL PROTECTED]> wrote: > > > > I'm working on getting up to speed with > > Hibernate. > > > > I started following > > > > these (http://hibernate.org/66.html) > > instructions > > > > but I'd rather have only 1 > > > > instance of Hibernate for all of my hibernated > > > > stuff. How far along is the > > > > deployer? I'm running the HEAD and the SAR > > seems > > > > happy. I'm willing to > > > > help the deployer along if you point me to it. > > > > > > > > Thanks, > > > > > > > > Andy > > > > > > > > > > > > cc: Gavin as I don't know if he's watching > > > > > > > > > > > > > > > > > > > > > > --- > > > > This SF.net email is sponsored by: IBM Linux > > > > Tutorials. > > > > Become an expert in LINUX or just sharpen your > > > > skills. Sign up for IBM's > > > > Free Linux Tutorials. Learn everything from the > > > > bash shell to sys admin. > > > > Click now! > > > > > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > ___ > > > > JBoss-Development mailing list > > > > [EMAIL PROTECTED] > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: IBM Linux > > Tutorials. > > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > ___ > > > 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: IBM Linux > > Tutorials. > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > ___ > > JBoss-Development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > 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: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM'
[JBoss-dev] [ jboss-Bugs-698682 ] DynamicQL concurrency problem
Bugs item #698682, was opened at 2003-03-06 14:47 Message generated for change (Comment added) made by loubyansky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=698682&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mauricio Hiroshi Nagaoka (mhnagaoka) Assigned to: Alexey Loubyansky (loubyansky) Summary: DynamicQL concurrency problem Initial Comment: I've been using DynamicQL with CMP Entity Beans in JBoss 3.0.6 and it's working quite well, except for a little problem. When I've more than one client running a DynamicQL query at the same time over the same CMP Entity Bean, sometimes I got the following exception: 2003-02-20 18:58:29,857 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException, causedBy: java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCom mand.execute(JDBCAbstractQueryCommand.java:161) at org.jboss.ejb.plugins.cmp.jdbc.JDBCDynamicQLQuery.e xecute(JDBCDynamicQLQuery.java:101) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCSelectorBridg e.execute(JDBCSelectorBridge.java:64) at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationH andler.invoke(EntityBridgeInvocationHandler.java:96) at org.jboss.proxy.compiler.Runtime.invoke (Runtime.java:59) at br.com.smbsoftware.webflow.tc.entity.TaskInfoBean$Pro xy.ejbSelectGeneric() at br.com.smbsoftware.webflow.tc.entity.TaskInfoBean.ejbH omeSelectGeneric(TaskInfoBean.java:731) at sun.reflect.GeneratedMethodAccessor436.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke Home(EntityContainer.java:1138) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractInterceptor.java:73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv okeHome(EntitySynchronizationInterceptor.java:207) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invokeHome (CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractInterceptor.java:73) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo me(EntityInstanceInterceptor.java:90) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInterceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo me(EntityCreationInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.java:62) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityInterceptor.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:129) at org.jboss.ejb.EntityContainer.invokeHome (EntityContainer.java:487) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv okeHome(BaseLocalContainerInvoker.java:230) at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke (LocalHomeProxy.java:110) at $Proxy198.selectGeneric(Unknown Source) at br.com.smbsoftware.webflow.tc.session.TaskControlBea n.getTaskInfoId(TaskControlBean.java:932) at sun.reflect.GeneratedMethodAccessor483.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatelessSessionContainer$ContainerInterc eptor.invoke(StatelessSessionContainer.java:660) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceIntercept or.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:92) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:204) at org.jboss.ejb.StatelessSessionContainer.invoke (StatelessSessionContainer.java:313) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke (StatelessSessionProxy.java:81) at $Proxy208.getTaskInfoId(Unknown Source) at br.com.smbsoftware.webflow.tc.TaskControlDelegate.get TaskInfoId(TaskControlDelegate.java:348) at br.com.smbsoftware.bombril.struts.SearchTaskAction.ex ecute(SearchTaskAction.java:87) at org.apache.struts.action.RequestProcessor.processActi onPerform(RequestProcessor.java:446) at org.apache.struts.action.RequestProcessor.process (RequestProcess
[JBoss-dev] [ jboss-Bugs-856982 ] Dynamic-QL not thread safe
Bugs item #856982, was opened at 2003-12-09 18:51 Message generated for change (Comment added) made by loubyansky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=856982&group_id=22866 Category: JBossCMP Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jacy Grannis (jacyg) Assigned to: Alexey Loubyansky (loubyansky) Summary: Dynamic-QL not thread safe Initial Comment: The implementation of dynamic-ql is not thread safe in 3.2.x (haven't tested in 4.x). Essentially, the problem is this: in the JDBCDynamicQLQuery execute() method, it compiles the dynamic jboss-ql, and calls super.setSQL();. That method call sets an instance variable in the super class. Then, after doing some more work, the execute() method eventually calls the super.execute() method. That method, in turn, eventually calls a method that uses the sql instance variable that was set via setSQL(). However, there is only one instance of the Query object for each finder per (not clear on this: container? jvm?). At any rate, if multiple threads are using the same dynamic-ql finder on the same ejb at the same time, the potential for a race condition exists, where one thread sets the sql variable, but by the time it runs the query, another thread has set it to something else. Clearly, this is very bad. I was able to replicate this behavior on 3.2.1 - 3.2.3. I have not found any other complaints about this behavior. Therefore, it seems quite likely to me that it has not been fixed, or even noticed. Attached to this message are rewrites of the queries that fix these problems. These rewrites are based on the 3.2.1 code-base (due to other issues we ran into with 3.2.2, we were still using 3.2.1; and 3.2.3 wasn't out for us to test before we started fixing this problem). If someone would like to take a look at these files and help merge them into the cvs-head, that would be much appreciated. Essentially, the fix consists of this: the JDBCAbstractQueryCommand is modified so that the only instance variables it has are ones which none of its subclasses will be modifying and which can be directly set in the constructor. A protected execute method is added that takes all the other parameters that used to be instance variables. A second abstract class, JDBCAbstractStaticSQLCommand, is added that extends JDBCAbstractQueryCommand. This class is the new super class for all the queries whose SQL is not dynamic (currently, everything but JDBCDynamicQLQuery). This class initializes all the instance variables in its constructor (so that the same efficiencies of only compiling the SQL statement once are still in play). It then uses those instance variables when executing the superclasses execute() method. Finally, JDBCDynamicQLQuery directly extends JDBCAbstractStaticSQLCommand and calls the execute method with its own dynamic (and locally scoped) variables. This seems to end all the mysterious errors we were getting that we traced back to using dynamic ql. Let me know if you have any questions, or concerns. -- >Comment By: Alexey Loubyansky (loubyansky) Date: 2003-12-21 20:08 Message: Logged In: YES user_id=543482 Fixed in Branch_3_2 and HEAD. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=856982&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 19:33 Message generated for change (Comment added) made by airsquig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Jason Tetrault (airsquig) Date: 2003-12-21 17:56 Message: Logged In: YES user_id=934522 Hello Sacha, Thomas, My apologies. The requirements I speak of are system requirements that I am trying to help our customer meet, note necessarily J2EE requirements. The requirement was a clustered application that works without sticky sessions. I just wanted to note that I have helped deploy and develop a few large scale web systems (not necessarily with JBoss) and this is not the first time I have seen this requirement. More of a planning note for JBoss. I like the technology and wanted to help make this as competitive as possible. At least the choice would be nice, be it a bug or a feature request. Regards, Jason -- Comment By: Thomas Peuss (tpeuss) Date: 2003-12-21 17:41 Message: Logged In: YES user_id=507779 Hello Sacha, now I got the point. I will change the clustering code to lookup the session in the clustering code in every situation. Should I apply this to 3.2 or HEAD first? CU Thomas -- Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 16:22 Message: Logged In: YES user_id=95900 > It is not uncommon for a highly redundant, large scale > deployment to expect this (Of any techno
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 20:33 Message generated for change (Comment added) made by tpeuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Thomas Peuss (tpeuss) Date: 2003-12-21 18:41 Message: Logged In: YES user_id=507779 Hello Sacha, now I got the point. I will change the clustering code to lookup the session in the clustering code in every situation. Should I apply this to 3.2 or HEAD first? CU Thomas -- Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 17:22 Message: Logged In: YES user_id=95900 > It is not uncommon for a highly redundant, large scale > deployment to expect this (Of any technology, not just J2EE) > from clustered technologies. I am working on a customer What are these "requirements", your posts (this and the first one) fail to explicit them clearly. There is a bug in the code (in that we don't always use the latest known information in the case of dual network failure, flip-flap effect), ok, but I don't see the "feature requirement" you mention. -- Comment By: Jason Tetrault (airsquig) Date: 2003-12-21 17:09 Message: Logged In: YES user_id=934522 Hello All, Two Notes, looking at the code I had the same worry Sacha did. This approach will only work if there is a tomcat container failure and restart. This will cause faulty data if failures result form network blips or overloaded machines. If this
Re: [JBoss-dev] Hibernate deployer?
Yes, eventually. Ivelin Ivanov wrote: Should we unify them and add to the jboss integration? Gavin? Ivelin --- Alexey Loubyansky <[EMAIL PROTECTED]> wrote: BTW, I use this same approach for CMP over Hibernate. Ivelin Ivanov wrote: Related to this, I just bundled a proposed addition to the Hibernate/JBoss integration. Gavin seemed to approve the design pattern. Hopefully my implementation is acceptable. http://hibernate.org/66.82.html Let me know what you think. Ivelin --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: HA JMS - singleton load balancing policy
As part of 4.0, we have to replace the smart proxies with clustered interceptors, we could reuse them then. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Ivelin Ivanov > Sent: dimanche, 21. décembre 2003 18:05 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Re: HA JMS - singleton load balancing policy > > > Yes, this is how it works now. > The client side of the HAIL uses the singleton > notifications, which in turn use the DRM. > The question is how to implement the client stub so > that it does not have to be part of the cluster. > > The smart RMI stubs take care of communicating with > the back end to receive regular snapshots of the > cluster view. There has to be additinal info about the > current singleton server. As Scott mentioned this can > be probably done as an extension to one of the load > balncing policies. > > However UIL2 does not use the smart RMI stubs. How to > merge them? Just use the RMI stuff for HAIL and don't > worry about UIL2 for now? > > Is the existing remoting at a stage that can replace > UIL2 without any loss of benefits ? I am not familiar > with it yet. > > Ivelin > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > The DistributedReplicantManager should be able to > > organize separate > > endpoints. HAIL or any other IL should interface > > with it. > > > > Bill > > > > Ivelin Ivanov wrote: > > > > > Ok, that is what I thought. > > > Let's see if this can be an easy fix. > > > Seems like UIL2 doesn't leverage the smart RMI > > stubs. > > > Any suggestions how to attack this? Have UIL2 use > > > smart RMI stubs somehow, write a completely > > different > > > IL based on the smart RMI stubs or reuse OIL. > > > > > > Currently the HAIL client stub is listening for > > > changes in the cluster topology and cancels the > > > connection when the singleton moves. > > > > > > > > > Ivelin > > > > > > --- Scott M Stark <[EMAIL PROTECTED]> wrote: > > > > > >>Its a variation of the FirstAvailable load > > balancing > > >>policy that > > >>chooses the singleton rather than one of the > > cluster > > >>nodes. > > >> > > >>-- > > >> > > >>Scott Stark > > >>Chief Technology Officer > > >>JBoss Group, LLC > > >> > > >> > > >>Ivelin Ivanov wrote: > > >> > > >> > > >>>An interesting problem came up related to HA JMS. > > >>>There is a need for a remoting mechanism that can > > >> > > >>not > > >> > > >>>only keep a current list of the cluster nodes, > > but > > >>>also know which one is the singleton node for a > > >>>particular service. > > >>> > > >>>Is this something that should be added to the > > >> > > >>roadmap > > >> > > >>>under remoting? Would it be implemented as a kind > > >> > > >>of > > >> > > >>>load-balancing strategy or some other way? > > >>> > > >>>Ivelin > > >>> > > >> > > >> > > >> > > >> > > > > > > --- > > > > > >>This SF.net email is sponsored by: IBM Linux > > >>Tutorials. > > >>Become an expert in LINUX or just sharpen your > > >>skills. Sign up for IBM's > > >>Free Linux Tutorials. Learn everything from the > > >>bash shell to sys admin. > > >>Click now! > > >> > > > > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > > >>___ > > >>JBoss-Development mailing list > > >>[EMAIL PROTECTED] > > >> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: IBM Linux > > Tutorials. > > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > ___ > > > 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: IBM Linux > > Tutorials. > > Become an expert in LINUX or just sharpen your > > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. > > Click now! > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > ___ > > JBoss-Development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign
Re: [JBoss-dev] Hibernate deployer?
Should we unify them and add to the jboss integration? Gavin? Ivelin --- Alexey Loubyansky <[EMAIL PROTECTED]> wrote: > BTW, I use this same approach for CMP over > Hibernate. > > Ivelin Ivanov wrote: > > > Related to this, I just bundled a proposed > addition to > > the Hibernate/JBoss integration. > > Gavin seemed to approve the design pattern. > Hopefully > > my implementation is acceptable. > > > > http://hibernate.org/66.82.html > > > > Let me know what you think. > > > > Ivelin > > > > --- > This SF.net email is sponsored by: IBM Linux > Tutorials. > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Hibernate deployer?
Pardon my negligence with JCA, but I think that the added benefit of the proposed mechanism releases the developer from the responsibility to manually worry about closing sessions. Reduces the need for these pesky try/catch/finally. Since the Hibernate session is on top of a DataSource, which is hopefully pooled, there is no need to pool sessions. Does this make sense, or I missed your point? Ivelin --- Adrian Brock <[EMAIL PROTECTED]> wrote: > On Sat, 2003-12-20 at 13:24, Ivelin Ivanov wrote: > > Related to this, I just bundled a proposed > addition to > > the Hibernate/JBoss integration. > > Gavin seemed to approve the design pattern. > Hopefully > > my implementation is acceptable. > > > > http://hibernate.org/66.82.html > > > > Let me know what you think. > > This looks like a cutdown version of what the jca > does in local transaction > mode, > except without any pooling of sessions. > > Doesn't Hibernate have a resource adapter already? > > I thought the point of the hibernate deployer was > to deploy the mappings? > > Regards, > Adrian > > > > > Ivelin > > > > > > --- Andrew Oliver <[EMAIL PROTECTED]> wrote: > > > I'm working on getting up to speed with > Hibernate. > > > I started following > > > these (http://hibernate.org/66.html) > instructions > > > but I'd rather have only 1 > > > instance of Hibernate for all of my hibernated > > > stuff. How far along is the > > > deployer? I'm running the HEAD and the SAR > seems > > > happy. I'm willing to > > > help the deployer along if you point me to it. > > > > > > Thanks, > > > > > > Andy > > > > > > > > > cc: Gavin as I don't know if he's watching > > > > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: IBM Linux > > > Tutorials. > > > Become an expert in LINUX or just sharpen your > > > skills. Sign up for IBM's > > > Free Linux Tutorials. Learn everything from the > > > bash shell to sys admin. > > > Click now! > > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > ___ > > > JBoss-Development mailing list > > > [EMAIL PROTECTED] > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > --- > > This SF.net email is sponsored by: IBM Linux > Tutorials. > > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > ___ > > 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: IBM Linux > Tutorials. > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: HA JMS - singleton load balancing policy
Yes, this is how it works now. The client side of the HAIL uses the singleton notifications, which in turn use the DRM. The question is how to implement the client stub so that it does not have to be part of the cluster. The smart RMI stubs take care of communicating with the back end to receive regular snapshots of the cluster view. There has to be additinal info about the current singleton server. As Scott mentioned this can be probably done as an extension to one of the load balncing policies. However UIL2 does not use the smart RMI stubs. How to merge them? Just use the RMI stuff for HAIL and don't worry about UIL2 for now? Is the existing remoting at a stage that can replace UIL2 without any loss of benefits ? I am not familiar with it yet. Ivelin --- Bill Burke <[EMAIL PROTECTED]> wrote: > The DistributedReplicantManager should be able to > organize separate > endpoints. HAIL or any other IL should interface > with it. > > Bill > > Ivelin Ivanov wrote: > > > Ok, that is what I thought. > > Let's see if this can be an easy fix. > > Seems like UIL2 doesn't leverage the smart RMI > stubs. > > Any suggestions how to attack this? Have UIL2 use > > smart RMI stubs somehow, write a completely > different > > IL based on the smart RMI stubs or reuse OIL. > > > > Currently the HAIL client stub is listening for > > changes in the cluster topology and cancels the > > connection when the singleton moves. > > > > > > Ivelin > > > > --- Scott M Stark <[EMAIL PROTECTED]> wrote: > > > >>Its a variation of the FirstAvailable load > balancing > >>policy that > >>chooses the singleton rather than one of the > cluster > >>nodes. > >> > >>-- > >> > >>Scott Stark > >>Chief Technology Officer > >>JBoss Group, LLC > >> > >> > >>Ivelin Ivanov wrote: > >> > >> > >>>An interesting problem came up related to HA JMS. > >>>There is a need for a remoting mechanism that can > >> > >>not > >> > >>>only keep a current list of the cluster nodes, > but > >>>also know which one is the singleton node for a > >>>particular service. > >>> > >>>Is this something that should be added to the > >> > >>roadmap > >> > >>>under remoting? Would it be implemented as a kind > >> > >>of > >> > >>>load-balancing strategy or some other way? > >>> > >>>Ivelin > >>> > >> > >> > >> > >> > > > --- > > > >>This SF.net email is sponsored by: IBM Linux > >>Tutorials. > >>Become an expert in LINUX or just sharpen your > >>skills. Sign up for IBM's > >>Free Linux Tutorials. Learn everything from the > >>bash shell to sys admin. > >>Click now! > >> > > > > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > >>___ > >>JBoss-Development mailing list > >>[EMAIL PROTECTED] > >> > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > --- > > This SF.net email is sponsored by: IBM Linux > Tutorials. > > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > ___ > > 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: IBM Linux > Tutorials. > Become an expert in LINUX or just sharpen your > skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 20:33 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 17:22 Message: Logged In: YES user_id=95900 > It is not uncommon for a highly redundant, large scale > deployment to expect this (Of any technology, not just J2EE) > from clustered technologies. I am working on a customer What are these "requirements", your posts (this and the first one) fail to explicit them clearly. There is a bug in the code (in that we don't always use the latest known information in the case of dual network failure, flip-flap effect), ok, but I don't see the "feature requirement" you mention. -- Comment By: Jason Tetrault (airsquig) Date: 2003-12-21 17:09 Message: Logged In: YES user_id=934522 Hello All, Two Notes, looking at the code I had the same worry Sacha did. This approach will only work if there is a tomcat container failure and restart. This will cause faulty data if failures result form network blips or overloaded machines. If this is the way HTTP Clustering is going to work, this at least needs to be highlighted in the JBoss Cluster document. It is not uncommon for a highly redundant, large scale deployment to expect this (Of any technology, not just J2EE) from clustered technologies. I am working on a customer system right now that this is a requirement for. I also believe
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 19:33 Message generated for change (Comment added) made by airsquig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Jason Tetrault (airsquig) Date: 2003-12-21 16:09 Message: Logged In: YES user_id=934522 Hello All, Two Notes, looking at the code I had the same worry Sacha did. This approach will only work if there is a tomcat container failure and restart. This will cause faulty data if failures result form network blips or overloaded machines. If this is the way HTTP Clustering is going to work, this at least needs to be highlighted in the JBoss Cluster document. It is not uncommon for a highly redundant, large scale deployment to expect this (Of any technology, not just J2EE) from clustered technologies. I am working on a customer system right now that this is a requirement for. I also believe it is common that J2EE application servers support this. Remember, many times you have a hardware based load balancer in the mix as well with replicated web servers (Which, yes you can configure for sticky sessions). The question really is, what happens to the load AFTER the failure with many users in a sticky session environment. Cheers Jason -- Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 15:41 Message: Logged In: YES user_id=95900 Hello Thomas, No, you shouldn't redirect back, but a second failure could make it go back to the first node, and it wouldn't us
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 20:33 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 16:41 Message: Logged In: YES user_id=95900 Hello Thomas, No, you shouldn't redirect back, but a second failure could make it go back to the first node, and it wouldn't use the last known state, this is what is described in the first scenario. If you hashmap is just holding *my* session, then simply drop it as the clustering code keeps both a serialized and non- serialized representation of the session, so it won't cost much. Why do you think that the tomcat clustering code was never designed to work without sticky sessions, I mean, which cases wouldn't work? As we can enabled synchronous replication, it should be ok IMHO (except in concurrent update), but in that case the spec is dump anyway. Cheers, sacha -- Comment By: Thomas Peuss (tpeuss) Date: 2003-12-21 16:01 Message: Logged In: YES user_id=507779 Sacha, I see the problem of short network hangs leading to a failover to another node. But why should I redirect a client back to his "old" node after it comes up again? The session on the old node is dead and will be removed after some time. The local session cache is there because the Tomcat session manager I derived the clustering session manager from has a HashMap where it holds its sessions. My understanding of t
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 20:33 Message generated for change (Comment added) made by tpeuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Thomas Peuss (tpeuss) Date: 2003-12-21 16:01 Message: Logged In: YES user_id=507779 Sacha, I see the problem of short network hangs leading to a failover to another node. But why should I redirect a client back to his "old" node after it comes up again? The session on the old node is dead and will be removed after some time. The local session cache is there because the Tomcat session manager I derived the clustering session manager from has a HashMap where it holds its sessions. My understanding of the clustering code is that it holds the serialized sessions and I have to deserialize them on access (which is costly - but what do I tell you ;-) ). If this is no longer the case we can remove the local session cache and use the cluster cache on every access. I think this is more straight forward anyway. But this is still no bug because the Tomcat clustering code was never designed to work without sticky session. CU Thomas -- Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 08:44 Message: Logged In: YES user_id=95900 I don't agree Thomas: while it is not really the best thing to do not to use sticky sessions (what if you have concurrent (frame) requests to the same session?), the described problem can occur even in sticky-session situations if we have a set of mino
[JBoss-dev] [ jboss-Bugs-863879 ] wrong tmp dir for JSP compiling
Bugs item #863879, was opened at 2003-12-21 11:47 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=863879&group_id=22866 Category: JBossWeb Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Lutz Walter (luwasoft) Assigned to: Nobody/Anonymous (nobody) Summary: wrong tmp dir for JSP compiling Initial Comment: With Jboss 3.2.3 (and other 3.2 versions before) on LINUX (JDK 1.4.2) in a production environment it seems to be the case, that the buildtin tomcat does not use the %JBOSS_HOME/server/*/tmp directory for temporary files while compiling JSP's. Instead it seems to use the working dir set before Jboss start. In a production environment, where the user running JBOSS has only write access to */tmp, */work, */log and */data JBOSS has to be started with: # cd $JBOSS_HOME/server/*/tmp # su wwwrun -c "$JBOSS_HOME/bin/run.sh" otherwise JSP compiling will fail because of missing file create/write permissions. This is not that primary problem, but i think it should be fixed anyway. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863879&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-863561 ] Out of memory exception using web-console
Bugs item #863561, was opened at 2003-12-20 15:36 Message generated for change (Comment added) made by mikezzz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863561&group_id=22866 Category: JBossServer Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: Michael Barker (mikezzz) Assigned to: Nobody/Anonymous (nobody) Summary: Out of memory exception using web-console Initial Comment: Running the web-console staright after a clean build of HEAD (200312201449) causes an Out Of Memory error. Version: 4.0 DR3 (cvs co 2003/12/20). Uname -a: Linux localhost.localdomain 2.4.22-1.2115.nptl_23.rhfc1.at #1 Wed Nov 26 19:54:30 EST 2003 i686 athlon i386 GNU/Linux JDK: java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) -- >Comment By: Michael Barker (mikezzz) Date: 2003-12-21 10:49 Message: Logged In: YES user_id=659570 I was using the default 64MB, I have upped it to 256MB its now OK. It looks like to run a "default" JBoss and the web-console it requires around 83MB of memory. Should the run.sh (and run.bat) be updated to default to a larger heap size? -- Comment By: Juha Lindfors (juhalindfors) Date: 2003-12-20 16:28 Message: Logged In: YES user_id=175239 What's your max heap setting for your JVM? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863561&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Test Results: 63 % ( 686 / 1085 ) - could do better. JBoss (HEAD/winxp/1.4.2_01) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Sun Dec 21 08:44:01 GMTST 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1085 Successful tests: 686 Errors:375 Failures: 24 [time of test: 2003-12-21.02-30 GMT] [java.version: 1.4.2_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2_01-b06] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows XP] [os.arch: x86] [os.version: 5.1] Useful resources: - http://jboss.kimptoc.net/winxp/1.4.2_01/logtests/testresults/reports/html//2003-12-21.02-30 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: BankEJB20StressTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: BankStressTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: BankStressTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: LocalUnitTestCase Test:testSetup Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: D:\jboss\jboss-head-test\build\output\testbuild\server\all\tmp\sessions\test\TreeCacheAopTester-doghozjx-16\doghp0t2-19.ser (The system cannot find the file specified) - Suite: TxConcurrentUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: ScopingUnitTestCase Test:testSingletons Type:failure Exception: junit.framework.AssertionFailedError Message: checkVersion(V2) is true === Sun Dec 21 08:44:01 GMTST 2003 === CYGWIN_NT-5.1 quarks2 1.5.4(0.94/3/2) 2003-09-12 23:08 i686 unknown unknown Cygwin === java -version java version "1.4.2_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode) --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-863113 ] Session Replication Inconsistent
Bugs item #863113, was opened at 2003-12-19 20:33 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jason Tetrault (airsquig) Assigned to: Thomas Peuss (tpeuss) Summary: Session Replication Inconsistent Initial Comment: This Bug report is a result of discussions on the JBoss Forums: http://www.jboss.org/index.html? module=bb&op=viewtopic&t=43602 Versions Replicated on: JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0 RC Version researched: JBoss 3.2.4 nightly Overview: It was noticed that HTTP Session Replication appeared inconsistent in a clustered environment. Further research showed that this was happening under round robin load balancing. Basically, it was found that a Session would replicate to another node ONCE and only Once, after that, the sessions are inconsistent. This shows itself in a apache round robin, NON Sticky load balanced configuration. On the third hit is when this bug shows itself. Now, after adding some trace, what I found is the following: It seem that the org.jboss.web.tomcat.session.ClusterManager has a local session container(sessions). If and only if the session is not in the local container, it will access the HTTPSessionMBean to get the session, which calls the org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes sionBeanImpl EJB. All works well. If node A is hit first, then Node B, Node B will get the session from the EJB that was set from node A. Now, Once both nodes have the session in their cache, the ClusterManager does not appear to go back to the MBean to re-get their session on get session requests, it just uses the version in local sessions container. This means that a session will replicate ONCE, and after that, tomcat uses its local version. This causes an inconsistent session state. It does look like each Servlet Container is updating there version in the EJB but, it is off because it is based off the inconsistent session it its local cache. Now, to test this, I made a quick code change to ClusterManager.findSession()method to get the session from the MBean and not use the one from sessions. This appeared to fix the problem (You have to call sessions.sessions.get(id) or it will break. Again, I did not spend much time on fixing it). Exactly how you want to fix this is up to you, I can see a few ways: 1. Somewhat like mentioned above. 2. Making the backend call the invalidate on the MBean to get rid of the sessions session. 3. others. Reproduction Information: This can be replicated by 1 JSP in a clustered environment in a session replicated web application. The attached JSP will replicate this problem. Basically, on each cluster, change the string being appended to the session key to the node name. In an apache round robin environment, one would expect that the string in the session would look like the following: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeB,NodeA Hit4: NodeA,NodeB,NodeA,NodeB Hit5: NodeA,NodeB,NodeA,NodeB,NodeA Right now, this is what happens: Hit1: NodeA Hit2: NodeA,NodeB Hit3: NodeA,NodeA Hit4: NodeA,NodeB,NodeB Hit5: NodeA,NodeA,NodeA Hit6: NodeA,NodeB,NodeB,NodeB Now, you do not necessarily need the apache round robin configuration but, it helps. Email me if you have any questions. Jason -- >Comment By: Sacha Labourey (slaboure) Date: 2003-12-21 08:44 Message: Logged In: YES user_id=95900 I don't agree Thomas: while it is not really the best thing to do not to use sticky sessions (what if you have concurrent (frame) requests to the same session?), the described problem can occur even in sticky-session situations if we have a set of minor network outages between the LB and the JBoss boxes. What is the purpose of this local session cache anyway? We already have the cache at the EJB level for http sessions, why do we need another one? Is it because its creation is costly? -- Comment By: Thomas Peuss (tpeuss) Date: 2003-12-20 12:03 Message: Logged In: YES user_id=507779 The JBoss HTTP-Clustering ONLY works with sticky session for performance reasons. Maybe we can introduce a configuration option that allows a use in a round-robin fashion (I am sill wondering why someone wants to do this). So this is not a bug. You can add this as a feature request. CU Thomas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=863113&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an ex
