We have installed jDLS as distrubuted lock listener service mode (jDLS -ibD).
We have 2 application servers Server1 and Server 2
Server 1 is the primary server and Server 2 is the secondary server
As part of maintenance activity we will shutdown the Server 1 for few hours. During those hours Server 2 will take control the jDLS and all the locks are managed by Server 2.
After few hours once the Server 1 is brought up, the locks are not getting released from Server 2. It goes to a dead lock situation.
Any ideas why jBASE jDLS is behaving like this? Any suggestions...
The listener process usually spawns new lock server process to handle each client lock process from secondary server. But for local requests there won’t be any new process spawned as the requests are local. It’s totally internal and can’t be changed.. Try to check if there was any change made in the new releases. Not sure about it though!
You can actually increase the size jDLS.As it can hold upto 1Lakh records.
E.g., jDLS -ibs 100000,30
The above allows us to lock one lakh records in 30 groups. By doing this you can overcome this issue.And also the system probably wont hang.
> We have installed jDLS as distrubuted lock listener service mode (jDLS > -ibD).
> We have 2 application servers Server1 and Server 2
> Server 1 is the primary server and Server 2 is the secondary server
> As part of maintenance activity we will shutdown the Server 1 for few > hours. During those hours Server 2 will take control the jDLS and all > the locks are managed by Server 2.
> After few hours once the Server 1 is brought up, the locks are not > getting released from Server 2. It goes to a dead lock situation.
> Any ideas why jBASE jDLS is behaving like this? Any suggestions...
The listener process usually spawns new lock server process to handle each client lock process from secondary server. But for local requests there won’t be any new process spawned as the requests are local. It’s totally internal and can’t be changed.. Try to check if there was any change made in the new releases. Not sure about it though!
You can actually increase the size jDLS.As it can hold upto 1Lakh records.
E.g., jDLS -ibs 100000,30
The above allows us to lock one lakh records in 30 groups. By doing this you can overcome this issue.And also the system probably wont hang.
> We have installed jDLS as distrubuted lock listener service mode (jDLS > -ibD).
> We have 2 application servers Server1 and Server 2
> Server 1 is the primary server and Server 2 is the secondary server
> As part of maintenance activity we will shutdown the Server 1 for few > hours. During those hours Server 2 will take control the jDLS and all > the locks are managed by Server 2.
> After few hours once the Server 1 is brought up, the locks are not > getting released from Server 2. It goes to a dead lock situation.
> Any ideas why jBASE jDLS is behaving like this? Any suggestions...
Before bringing Server1 back on line you should stop all T24 processes
The switch to 'Server2' , when Server1 is taken offline, is a 'one way process'
So existing processes will continue to use 'Server2' ( only ) for locking
Any new processes, started after Server1 is brought back on line, will attempt to use BOTH Server1 and Server2 in resilient mode, leading to 'lock contention' and 'mismatches'
> We have installed jDLS as distrubuted lock listener service mode (jDLS > -ibD).
> We have 2 application servers Server1 and Server 2
> Server 1 is the primary server and Server 2 is the secondary server
> As part of maintenance activity we will shutdown the Server 1 for few > hours. During those hours Server 2 will take control the jDLS and all > the locks are managed by Server 2.
> After few hours once the Server 1 is brought up, the locks are not > getting released from Server 2. It goes to a dead lock situation.
> Any ideas why jBASE jDLS is behaving like this? Any suggestions...
So the only solution is to bring the server 2 down as part of killing / stopping all T24 processes before bringing up the server 1, and once server 1 is up subsequently the server 2 also needs to be brought up. Please let me know if my understanding is correct / wrong.
Is there any better setup of jdls in server 1 and 2, that is recommended to do away with this problem
On Sat, Dec 10, 2011 at 4:18 AM, pat <pat...@gmail.com> wrote: > Before bringing Server1 back on line you should stop all T24 processes
> The switch to 'Server2' , when Server1 is taken offline, is a 'one way > process'
> So existing processes will continue to use 'Server2' ( only ) for > locking
> Any new processes, started after Server1 is brought back on line, will > attempt to use BOTH Server1 and Server2 in resilient mode, leading to > 'lock contention' and 'mismatches'
> On Dec 7, 6:25 am, "www.t24all.com" <eb.phan...@gmail.com> wrote: > > Hi,
> > We have installed jDLS as distrubuted lock listener service mode (jDLS > > -ibD).
> > We have 2 application servers Server1 and Server 2
> > Server 1 is the primary server and Server 2 is the secondary server
> > As part of maintenance activity we will shutdown the Server 1 for few > > hours. During those hours Server 2 will take control the jDLS and all > > the locks are managed by Server 2.
> > After few hours once the Server 1 is brought up, the locks are not > > getting released from Server 2. It goes to a dead lock situation.
> > Any ideas why jBASE jDLS is behaving like this? Any suggestions...
> IMPORTANT: Type T24: at the start of the subject line for questions > specific to Globus/T24
> To post, send email to jBASE@googlegroups.com > To unsubscribe, send email to jBASE-unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/jBASE?hl=en
