Re: Tomcat 9 Session replication

2022-01-31 Thread Keiichi Fujino
Hi

If you use StaticMembershipService, you must set
Cluster#channelStartOptions to 15 (default).


2022年1月31日(月) 16:47 Alan F :

> OK with your advice I tried what I thought would work from example and
> doesn't at all. The old example below works but this doesn’t even detect
> members.
>
> Below is example to which Im using on both nodes which are remote to
> eachother.
>
>
> channelSendOptions="8" channelStartOptions = "3">
>   expireSessionsOnShutdown="false"
>notifyListenersOnReplication="true"/>
>
>   
>
>  className="org.apache.catalina.tribes.membership.StaticMembershipService">
>  className="org.apache.catalina.tribes.membership.StaticMember"
>   port="4110"
>   host="local-tomcat"
>   domain="tomcat-pc2"
>
> uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0}" />
>  className="org.apache.catalina.tribes.membership.StaticMember"
>   port="4110"
>   host="remote-tomcat"
>   domain="tomcat-pc2"
>
> uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}" />
> 
>
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>  address="local-tomcat"
>  port="4110"
>  autoBind="9"
>  selectorTimeout="2000"
>  maxThreads="6"/>
>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>  className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>
>
> className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
> staticOnly="true"/>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
> />
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
>
>
>   
>
>filter=""/>
>className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/opt/tomcat/war-temp/"
>  deployDir="/opt/tomcat/war-deploy/"
> watchDir="/opt/tomcat/war-listen/"
> watchEnabled="true"/>
>className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>  
>
>
> -Original Message-
> From: Mark Thomas 
> Sent: 28 January 2022 18:15
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9 Session replication
>
> On 28/01/2022 17:05, Alan F wrote:
> > We are currently getting traffic from all cluster members in other
> environments using .staticmember opposed to multicast can I confirm why
> this is see below.
> >
> > What do we need to set here for a clustered pair to make them unique
> > and talk to eachother only without seeing traffic from other members
> > in Catalina.out
> >
> > This is how they are currently configured as you can see only difference
> between nodes is the receiver and member ips are reversed. Im concerned
> uniqueID is the same, do we also need to specify domain?
>
> uniqueID should be unique at least within the subnet, ideally globally.
>
> Yes, you should use a separate domain for each cluster.
>
> Looking at your config:
>
> You are missing the local member definition
> https://tomcat.apache.org/tomcat-10.0-doc/config/cluster-interceptor.html#Static_Membership
>
> The deployer should be defined under the cluster, not under an interceptor.
>
> Mark
>
> >
> > WE have hostname A and B if you could check below:
> >
> > HOSTNAME A config
> >
> > 
> >
> >  channelSendOptions="8">
> > className="org.apache.catalina.ha.session.DeltaManager"
> > expireSessionsOnShutdown="false"
> > notifyListenersOnReplication="true"/>
> >
> >
> > 
> >   className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> >   className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" />
> >  
> >   >  address="hostnameA"
> >  autoBind="0"
> >
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> >  maxThreads="6"
> >  port="4100"
> >  selectorTimeout="5000"
> >  />
> >  
> >   className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
> staticOnly="true"/>
> >   className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
> />
> >   className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
> >   >
> className="org.apache.catalina.t

Re: StaticMembers within Multiple Clusters

2019-02-12 Thread Keiichi Fujino
2019年2月12日(火) 1:28 Tim K :

> On Fri, Jan 18, 2019, 12:44 PM Tim K  wrote:
>
> > On Fri, Jan 18, 2019 at 11:05 AM Christopher Schultz
> >  wrote:
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Tim,
> > >
> > > On 1/18/19 06:38, Tim K wrote:
> > > > Thanks for this.  The video helps explain it a bit better than the
> > > > documentation.  So I set it up with a backup manager instead of the
> > > > delta manager, changing the channelSendOptions to 6 for the
> > > > cluster.
> > >
> > > If you think you can help clarify the documentation, patches are of
> > > course always welcome.
> > >
> > > > From a maintenance standpoint, what is the best way to stop/start
> > > > the nodes without losing sessions; one at a time, letting it fully
> > > > come up before moving on to the next one (like a ripple restart)?
> > > > I presume you don't want too many nodes to be down at a single
> > > > time.
> > >
> > > I definitely wouldn't bring two down simultaneously if your can avoid
> > > it. The cluster needs time to re-stabalize after the loss of a member,
> > > meaning that new backup nodes must be selected for each session and
> > > then the sessions must be transmitted to those backups nodes. If you
> > > have small amounts of data in the sessions, this will probably be
> > > fairly fast. If you have lots of data or a very busy network, it will
> > > take longer.
> > >
> > > I would recommend setting-up a scenario (even in production) where you
> > > intentionally disable a node in the cluster and watch to see how long
> > > the cluster takes to re-stabalize. I think you'll learn a lot from
> > > that exercise and it will help you plan for scheduled maintenance and
> > > downtime.
> > >
> > > - -chris
> >
> > Is there a way to tell which server was assigned as the primary and
> > backup roles?
> >
> > When I stop a member, is it this line which would tell me how long it
> > took to sync up the sessions?
> > Relocation of map entries was complete in [X] ms.
> >
> > Another question, I'm using the StaticMembershipService; do I need to
> > define a LocalMember for each of my nodes or is that optional/assumed?
> >
> > Also, I recall reading something about the uniqueId might not really
> > be used?  Do I need to set that for each member?
> >
>
>
> I'm noticing my SSO cookie is being removed when I force myself to another
> node.  Is this a bug?
>
>
>
Are you using SSO(org.apache.catalina.authenticator.SingleSignOn)?
DeltaManager/BackupManager replicate sessions. They do not replicate SSO
entries.

If you want to replicate SSO Entry in cluster, you can use
ClusterSingleSignOn.

http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-valve.html#org.apache.catalina.ha.authenticator.ClusterSingleSignOn



-- 
Keiichi.Fujino


Re: Protecting a cluster from malicious membership

2019-02-11 Thread Keiichi Fujino
2019年2月12日(火) 1:44 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 2/11/19 03:49, Mark Thomas wrote:
> > On 10/02/2019 14:37, Christopher Schultz wrote:
> >> All,
> >>
> >> I'm looking at the security of Tomcat's Clustering components,
> >> and I think that the following are true. Please let me know if
> >> anything in here is inaccurate:
> >>
> >> 1. a. Default membership uses multicast b. Multicast (UDP) can't
> >> be authenticated c. Therefore multicast membership cannot be
> >> secured on its own d.  ... unless you use the "domain" attribute
> >> as a kind of "password" to get into a segment of the cluster
> >>
> >> 2. a. Static membership enumerates all members of the cluster on
> >> all nod es b. Therefore, joining a malicious node to the cluster
> >> is unlikely
> >>
> >> 3. a. Adding EncryptInterceptor encrypts i. TcpFailureDetector
> >> traffic ii. All actual content traffic b. Therefore, adding
> >> EncryptInterceptor effectively secures the cluster, even if the
> >> membership cannot be completely locked-down
> >
> > Nothing jumps out at me as wrong.
> >
> > Also, I'd expect to see a bunch of errors at the valid nodes when
> > they failed to decrypt messages from the invalid nodes. That should
> > provide a clear indication that something unexpected was going on.
>
> Yep, that's detection, though... not prevention.
>
> Thanks for the review.
>
> A follow-up to 1d above... if I try to (maliciously) join a cluster
> which has been separated into domains whose identities I do not know,
> I just end up in a (potentially unnamed) domain all by myself, right?
> So I'm a "member" of the cluster, but I can't meaningfully interact
> with any of the other legitimate members?
>
>
If DomainFilterInterceptor has been enabled in cluster,
you can't interact with any of the other legitimate members.




> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxhpngACgkQHPApP6U8
> pFgh/A/9HCmE9xBbfLKPq7gcjsPWJlvX3zd2RomvLT0Psr+XvVwja2sd4o20enNg
> 68+NB60AgKq2YVa4h5vQvn3/EPOaqWLSsR/j6EvHNwnko27STg8PGpNdpGCbnrE0
> EcAOxVOI3BjP2m7o8dW/uALwXaFRFJK0Ijpk6IdkMORSxr6cScoEXodHzjs/x1M+
> rM/laF0tQ19W58J6bGmHw92mYFZ2aho2qhQKH6J/N4WnR5lBlrb3rwuTZgpLomxO
> EO2BRwPmonGsYfRG74+4jMsV9dZnlWplRrgPbbCCgOYC0nhdTNRXkXBeUfhd9m3h
> BRPkG+DbpysVC+6nyTqOpMJy7iGaY/cRyEJK8T5cvnQIF5ByjbXMR92qVaLCRkzA
> al+nRZA2GG56kWBc5vWhRg0++P7CXPKZmMe2IvUGYyBsuVBDCMTydymiA3Q8mvcc
> 1pV3n+or7yXQjfN1Ak/DdBAnPcI2ykwA1LJazuPOfAk6cyZy1ebBHYwPGAHDBFKz
> hXiL/3rmjG8E3+hK3nbJ22xhTmnAh5/B2V+pkRf6gCk3TbcsPDgc5K++1yri56EQ
> 4t4bGwmv3hRgy6EYpfiVZfXwLl3J/eThYeXdzbmt0eY4bDVmHxcrBxUf3yanYiY2
> zFh6q7CLyjgqYuaV1QLYzP17fAWdSY+xtATNANdvYquqxREQV5o=
> =x0Xw
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Keiichi.Fujino


Re: StaticMembers within Multiple Clusters

2019-01-15 Thread Keiichi Fujino
Hi

If you use StaticMembershipInterceptor, you must set the
Cluster#channelStartOptions to 3 to avoid starting membershipservice.
If you are using Tomcat 9, you can also use StaticMembershipService instead
of StaticMembershipInterceptor.


2019年1月10日(木) 22:39 Tim K :

> On Wed, Jan 9, 2019, 2:16 PM Christopher Schultz <
> ch...@christopherschultz.net wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Tim,
> >
> > On 1/9/19 10:39, Tim K wrote:
> > > I'm trying to split 4 separate tomcat instances into 2 clusters
> > > (2x2) to try and avoid the all-to-all traffic, but even when
> > > setting up the Receiver and Static members to only speak to 1 other
> > > instance, some still seems to find and add the other members
> > > outside of the defined config to the wrong cluster.  I read that
> > > mcast is still used when you have StaticMembers, could that be
> > > causing this issue?
> >
> > Multicast is only used for membership, so if you are using static,
> > there should be no multicast.
> >
> > Do you want to post your configuration(s)?
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw2SIEACgkQHPApP6U8
> > pFh//A//WldkBxcRVWZ0Nj/FVjFqdhxr8dkystbk114wk8pjF/h5JOSmncQjvUn6
> > 999ZT54rXToS+Dl2svp9imR266o0+56bUvJVXG2O4NK7TQZsEsBdOsqfnWPoHBM3
> > kYS7lhzhlpmw1SDFlKVW0PnRX9acah5+SfVci5gL0cWTVqSkdmm4P6v2wqH1z7ej
> > AeMZ0w2LaoRH0TTxJk8cD2vJpvnB3oNjrtUhHZCPJCraITPHhFNFMOSmhhf3+e1S
> > K63D6l9kE3x4WDNtxKBBjr+5FaULM6kL5DotQlJPo0j7I4mL9DBgt2HkgTfoS39m
> > M7QBGBR4tZ1zRIJiGXQRViMRhqL+Xjny61RxtU7zUlfWSChTEonUiv5z6aZ7q5n2
> > xz1Evrw+gLmoR+YecOazMHef/7z6GFNCGyE80BFbR8LgHeOubaPfY+zhYw6iWSQP
> > eHt32x48vzPewYlV1HLJR7C1oXhFPN9QVT2r+UENcsMtlDdWIhaflw6nb3qXhP8N
> > t4xqlUJebON1KolHRXXReNgz6TieKLmup1jSgRvVhohSYBOputLB01PY5S7E6vLy
> > 33EZGHbCOWlZzC1qyiXRd7jIfkdsQ9oRRHknty1gi0id/20M+iqYS22ZggnXMtFX
> > P0lORhhEiWBSyMHytrIb+uO7HglocrSuQfgVaoAkiaRUDtyBdHg=
> > =PM9e
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> Essentially I'm trying to have server1 and server2 only in cluster1 and
> server3 and server4 in only cluster2, but for some reason, members are
> getting added to clusters that they aren't configured for.
>
>
>
> server1 config:
>
>  channelSendOptions="8">
>
>  className="org.apache.catalina.ha.session.DeltaManager"
> expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
>
>  className="org.apache.catalina.tribes.group.GroupChannel">
>
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto" port="4000" autoBind="100" selectorTimeout="5000"
> maxThreads="6"/>
>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>
>  className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>
> 
>
> 
> className="org.apache.catalina.tribes.group.interceptors.EncryptInterceptor"
> encryptionKey="Removed" />
>
> 
> className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"/>
>
> 
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>
> 
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
>
> 
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
>
>  className="org.apache.catalina.tribes.membership.StaticMember"
> host="server2" port="4000" domain="cluster1"
> uniqueId="{1,0,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/>
>
> 
>
> 
>
>  className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
>
>  className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>  className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>
> 
>
>
>
> server2 [everything the same except the  is]:
>
>  host="server1" port="4000" domain="cluster1"
> uniqueId="{0,0,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/>
>
>
>
> server3 [everything the same except the  is]:
>
>  host="server4" port="4000" domain="cluster2"
> uniqueId="{4,0,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/>
>
>
>
> server4 [everything the same except the  is]:
>
>  host="server3" port="4000" domain="cluster2"
> uniqueId="{3,0,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/>
>


-- 
Keiichi.Fujino


Re: 9.0.13 encrypted cluster traffic

2018-12-24 Thread Keiichi Fujino
2018年12月23日(日) 2:10 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Keiichi,
>
> On 12/21/18 02:58, Keiichi Fujino wrote:
> > 2018年12月21日(金) 12:11 Christopher Schultz
> > :
> >
> > Tim,
> >
> > On 12/20/18 10:18, Tim K wrote:
> >>>>>
> >>>>> I just downloaded and tried 9.0.14 but I'm still getting
> >>>>> the same BadPaddingException upon starting the second
> >>>>> instance.  I confirmed the encryptionKey matches on my two
> >>>>> instances.
> >>>>>
> >>>>
> >>>> Maybe something is wrong with my config?  For this test, I
> >>>> have both Tomcats on the same server using different ports:
> >
> > This is the only thing that matters to the encryption interceptor:
> >
> >>>>  >>>> className="org.apache.catalina.tribes.group.interceptors.EncryptInt
> erc
> >
> >>>>
> eptor"
> >>>>
> >>>>
> > encryptionKey="e0f2cdf931e99fdce0453964294f97f3" />
> >
> > I'm not sure if the order of encrypt/asyncdispatch interceptors
> > matters much.
> >
> >
> >
> >> Hi.
> >
> >> The case of using TcpFailureDetector, there is a case to write
> >> directly without passing through the interceptor chain.
> >
> >> TcpFailureDetector#memberAlive writes the channel data directly
> >> to outputstream without passing through the interceptor chain.
> >> However, when receiving this channel data, It passes through the
> >> interceptor chain. So, it must be received by TcpFailureDetector
> >> before decrypt of EncryptInterceptor. That is, the order is
> >> important. The order is EncryptInterceptor ->
> >> TcpFailureDetector.
>
> How's this for an update to the EncryptInterceptor documentation:
>
> "
> If using the TcpFailureDetector, the
> EncryptInterceptor
> must be inserted into the interceptor chain before the
> TcpFailureDetector. This is becuase the
> TcpFailureDetector writes channel data directly
> without using
> the remainder of the interceptor chain, but on the receiving side,
> the message still goes through the chain (in reverse). Because of this
> asymmetry, the EncryptInterceptor must execute
> before
> the TcpFailureDetector on the sender and after
> it on the receiver.
> "
>
>
Hi Chris.

Writing channel data directly is only for member verification.
Normal message are sent/received via the interceptor chain.
So, It may be better to add a sentence that interprets that writing channel
data directly is only for member verification.
such as, "When TcpFailureDetector validates cluster members..." etc.



> ??
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlweb+MACgkQHPApP6U8
> pFibAhAAuQWi3IGaGRGGwZEHYo9jMB9gdxGkZvQGMEK4naN2KgMkzZ56wTxWRwFh
> SEV6yHj6Tz+MERc6YL2st3Hm8VH6DgwEth1g1SmLZGM0JxD4HgqTwtVE9JZk9s4Y
> dMCgRR+O09bUh0fnCOybcOHeMZv1SewPFhXq8e/rquTbJAhljRhCrANkzRmo5/05
> WS+DsG78EVrjMG/X8uZIkkBOO43TzwTyAWNrX7u3DwUvf01idgHUceBQ/pRVC+L9
> a4TwypZjYkxJcLeHexzytXYLs8j/r8JtrPYFZfTeQvnlFdDkAcFgYL+CjfjKRTwo
> GPJyMU8HjxAfROe0HsRXwtX/OL0XTDq21bwE7yNTCtV1NcnsLSY74eh7WtwMgIKx
> kmNva4roGCeb+IQAC2QRnXmenB3qX2RN2ZrY3KWEq2s+UJP7PTf3Xga5ov/OJ0ce
> SE8UIuXfmh8IS7nZPn0mFwflbB9xjJZZV8c/oScQflAJKtVjc3mQ6b+29Jfx+zMI
> imvx+B7szFkccjtIjZQlPHqgW0MbnuflqiVBUb8tH29adDOWELRPook3V6htHdBA
> 1Izbpng+dVU2R2xEQdtdcevUKbaIvmB8xYGRgilu//o/1RrC8wzGqZuXaiomBT01
> Q/wIOQjjXKvVELoAu7Ym23KEv+IDrZAmtZy7QWiBP5azPwbc4sA=
> =wOVI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Keiichi.Fujino


Re: 9.0.13 encrypted cluster traffic

2018-12-20 Thread Keiichi Fujino
2018年12月21日(金) 12:11 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Tim,
>
> On 12/20/18 10:18, Tim K wrote:
> >>
> >> I just downloaded and tried 9.0.14 but I'm still getting the same
> >> BadPaddingException upon starting the second instance.  I
> >> confirmed the encryptionKey matches on my two instances.
> >>
> >
> > Maybe something is wrong with my config?  For this test, I have
> > both Tomcats on the same server using different ports:
>
> This is the only thing that matters to the encryption interceptor:
>
> >  > className="org.apache.catalina.tribes.group.interceptors.EncryptInterc
> eptor"
> >
> >
> encryptionKey="e0f2cdf931e99fdce0453964294f97f3" />
>
> I'm not sure if the order of encrypt/asyncdispatch interceptors
> matters much.
>


Hi.

The case of using TcpFailureDetector, there is a case to write directly
without passing through the interceptor chain.

TcpFailureDetector#memberAlive writes the channel data directly to
outputstream without passing through the interceptor chain.
However, when receiving this channel data, It passes through the
interceptor chain.
So, it must be received by TcpFailureDetector before decrypt of
EncryptInterceptor.
That is, the order is important.
The order is
EncryptInterceptor -> TcpFailureDetector.


>
> I copy/pasted your key into the TestEncryptInterceptor unit test and I
> didn't get any errors. I generated 4 new 32-character (16-byte) keys
> and tried all of them and didn't get any errors.
>
> Oddly, the very first time I copy/pasted it from your email message
> into the tester it failed with BadPaddingException, but when I
> re-copied "just in case" it stopped failing. Can you download and
> build the 9.0.14 source and run that unit test in your environment?
> Like this:
>
>   $ ant test
> - -Dtest.entry=org.apache.catalina.tribes.group.interceptors.TestEncryptIn
> terceptor
>
> If that works, try copy/pasting your key into the source file of the
> test -- it's right up at the top, called "encryptionKey128" -- then
> save and re-run the test (ant will recompile it). If that works...
> then I'm stumped.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwcWdEACgkQHPApP6U8
> pFhClRAAnW4mZ59yG6exLzJqv6nNW8wdUhrLY2eGWFroWN3JMADU7kwA14ndNZfv
> iOEIaaE1zvtEiScivqAj6VhIetrb/j07NUSX8eoUYzsEWS6GlFtAY53ok/6xPX4F
> 5MUxJTjklQr16C/IAx+4mgbTE/eUKWodfE58Q5sZo6acKxmikwMFFdRkGfqlkLe3
> Gmed6zCHMjbhr/yq3g7J484wEqmzYXhGcOHHfNERxunjrcnfd4m4pqQhjTiLMNRN
> wRG6wovEbAwv3P/PPlGu30d776m3OKNAaYIh17AHFEB2dS6Xn5GToMHAyp5nmRFs
> Tt+bWhWnB37EmsvvvU+yH17CqUtatdnCw1UHVseoVZGmzefpxQdwuh57Hs1NLSSN
> 683giOomSALGWupBd6XV56XfV19k+PuB1gv2He4AfJRmBzJhyS4WTJgwalMcIEOF
> 4r2hmJQGhoopTZR3grvycLTzKvSH/s35Lbf2C1BSxZ+lxsig46NYeemX8xe9H39g
> s/30ACCNV3h2LUjrqHTQ+wT4VBtOvC7VviZnWzaegmjDuP7xPEENr2uYt230eRGt
> Z+WkHrhTkLchwmdK4v1ziCNPgggfI8vEM6IOQwxxmwiwthYpfxA7zDBFgqiJUMO4
> HN/74VauFxG2YeK4LFPYd3i65fCYZRqLceMuzfquYgdmX6ccgQQ=
> =IAd9
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Keiichi.Fujino


Re: [ANN] New committer: Woonsan Ko

2018-12-19 Thread Keiichi Fujino
Congratulations!
Welcome Woonsan!

2018年12月19日(水) 18:56 Mark Thomas :

> On behalf of the Tomcat committers I am pleased to announce that
> Woonsan Ko (woonsan) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Keiichi.Fujino


Re: Translations update

2018-12-14 Thread Keiichi Fujino
2018年12月14日(金) 13:46 Woonsan Ko :

> Hi all,
>
> Korean translation has just got to 100% line! Congrats to all the
> contributors!
> I also see Japanese fellows making a breakthrough, approaching the
> finish line. Congrats in advance!
> I will proofread Korean translations next week one more or two.
> Perhaps I can write something about how each term, phrase and sentence
> were to be translated for other (Korean) translators.
>
> Hi.
Congrats Woonsan.
Great work!
The goal of Japanese translation is coming soon,
I’m going to keep translating.


> Cheers,
>
> Woonsan
>
> On Wed, Nov 21, 2018 at 6:58 PM Mark Thomas  wrote:
> >
> > Hi all,
> >
> > I wanted to let you know about the amazing progress that is being made
> > on the Tomcat translations at
> > https://poeditor.com/join/project/NUTIjDWzrl
> >
> > In the short time since this effort has started the community has
> > achieved the following:
> >
> > - French has increased from 18% to 64% coverage
> > - Simplified Chinese has been added and has already reached 32% coverage
> > - Korean has been added and has reached 10% coverage
> > - German has increased from 2% to 7% coverage
> > - Brazilian Portuguese has been added and has reached 4% coverage
> > - Spanish has increased from 42% to 44% coverage
> >
> > as well as a smaller number of additions and corrections to another 6
> > languages.
> >
> > A big thank you to everyone who has contributed.
> >
> > There is still lots to do so if you would like to help out please join
> > us at:
> > https://poeditor.com/join/project/NUTIjDWzrl
> >
> > Thanks,
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Keiichi.Fujino


Re: How to make database connection pool show in JMX

2018-01-25 Thread Keiichi Fujino
Hi

The Docs of jdbc-pool describe like this.
==
If you're running outside of a container, you can register the DataSource
yourself under any object name you specify, and it propagates the
registration to the underlying pool. To do this you would call
mBeanServer.registerMBean(dataSource.getPool().getJmxPool(),objectname).
Prior to this call, ensure that the pool has been created by calling
dataSource.createPool().
==
http://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html#JMX

Thus you must register the DataSource as MBean.


2018-01-24 10:48 GMT+09:00 Pawel Veselov :

> Hello.
>
> I'd like to get some JMX stats out of the JDBC connection pools. But
> they don't seem to register
> in JMX, even though they are based on ConnectionPoolMBean.
>
> I do create the pools programmatically, by binding the factory into
> the JNDI, the creation snippet is
> copied below. When I search for JMX objects, I don't see anything that
> looks like the pool info,
> but I'm also not sure what the object name is supposed to be. I expect
> it to be in "Catalina"
> domain, though some of the code I saw suggests it may be in
> "tomcat.jdbc" domain instead... I
> don't have any "tomcat." domains at all.
>
> Any clues are appreciated.
>
> --
> Properties p = new Properties();
>
> p.setProperty("type", "javax.sql.Datasource");
> p.setProperty("defaultAutoCommit", "false");
> // <...> set some other properties here
> // enable JMX
> p.setProperty("jmxEnabled", String.valueOf(Boolean.TRUE));
> // JNDI of the actual data source
> p.setProperty("dataSourceJNDI", pooledDSName);
> Class dsfClass =
> Class.forName("org.apache.tomcat.jdbc.pool.DataSourceFactory");
> Object dsf = dsfClass.newInstance();
> Method m = dsfClass.getDeclaredMethod("createDataSource",
> Properties.class);
> return m.invoke(dsf, p);
> // the result is bound into JNDI
> --
>
> Thank you!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 


Re: Beginner help setting up test vertical cluster

2017-11-01 Thread Keiichi Fujino
Hi Dave.

Your Interceptor settings are as follows.


> 
> 
> 
> 
>uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}">
>className="org.apache.catalina.tribes.membership.StaticMember"
> domain="clustertest" host="xxx.xxx.xxx.xxx" port="4001" securePort="-1"
> uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0}">
> 
> 
> 
>
>
>
You specified domain="clustertest" in , but DomainFilterInterceptor
does not have a domain setting.
If you want to filter by domain, you have to set domain="clustertest" to
DomainFilterInterceptor.
if you do not want to filter by domain, you have to remove
domain="clustertest" from   or remove DomainFilterInterceptor.

Also, if you use DomainFilterInterceptor with static membership, you must
list it above StaticMembershipInterceptor.

e.g.
TcpPingInterceptor->TcpFailureDetector->DomainFilterInterceptor->StaticMembershipInterceptor
or
DomainFilterInterceptor->TcpPingInterceptor->TcpFailureDetector->StaticMembershipInterceptor


-- 
Keiichi.Fujino


Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

2017-10-17 Thread Keiichi Fujino
Hi

You have set factory="org.apache.tomcat.jdbc.pool.DataSourceFactory".
In other words, you do not use (tomcat)DBCP, you are using Tomcat jdbc-pool.

In DBCP, the default of rollbackOnReturn attribute is true.
However, in Tomcat jdbc-pool, the default of rollbackOnReturn( and
commitOnReturn
) attribute are false.

see:
http://commons.apache.org/proper/commons-dbcp/configuration.html
http://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html


2017-10-12 6:21 GMT+09:00 Chris Cheshire :

> Working on a migration from 7 to 8.5, and in it I am now using the
> tomcat dbcp, instead of apache commons dbcp. I have found that with no
> other changes to the db code (except the factory param for the
> resource), it is working fine other than there is an implicit commit
> happening when I close a connection, even with autocommit turned off
> in mysql config, resource config AND in my code.
>
> Resource config :
>
>auth="Container"
>   type="javax.sql.DataSource"
>   driverClassName="com.mysql.jdbc.Driver"
>   url="jdbc:mysql://localhost:3306/mydb?useUnicode=true&
> characterEncoding=utf8&useSSL=false"
>   factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>   username=""
>   password=""
>   maxActive="150"
>   maxIdle="25"
>   maxWait="6"
>   removeAbandoned="true"
>   removeAbandonedTimeout="300"
>   logAbandoned="true"
>   validationQuery="/* ping */"
>   testOnBorrow="true"
>   testWhileIdle="true"
>   timeBetweenEvictionRunsMillis="60"
>   defaultAutoCommit="false" />
>
> Only thing changed in that from 7.x to 8.5.x is the factory was
> org.apache.commons.dbcp.BasicDataSourceFactory. I am using Connector/J
> 5.1.44 (latest version).
>
>
> Getting a connection boils down to this in my code (pieces pulled out
> of factories and other classes)
>
> (Support class in web code)
> public static DataSource getDataSource() {
> try {
> return (DataSource)new
> InitialContext().lookup("java:comp/env/" +
> ServletContextParameters.getDatabaseResourceName());
> }
> catch (NamingException ex) {
> throw new RuntimeException("unable to find datasource", ex);
> }
> }
>
>
> (DAO Factory implementation)
> public MySQLDAOFactoryImpl(@NotNull DataSource dataSource) {
> this.dataSource = dataSource;
>
> try {
> this.dbConn = this.dataSource.getConnection();
> this.dbConn.setAutoCommit(false);
> this.dbConn.setTransactionIsolation(Connection.TRANSACTION_READ_
> COMMITTED);
> }
> catch (SQLException ex) {
> throw new DAOException("unable to get database connection", ex);
> }
> }
>
> @Override
> public void close() {
> try {
> if (this.dbConn != null) {
> this.dbConn.close();
> }
> }
> catch (SQLException ex) {
> throw new DAOException("error closing database connection", ex);
> }
> }
>
>
> If I do
>
> daoFactory = new MySQLDAOFactoryImpl(getDataSource());
>
> // update #1
> daoFactory.commit()
>
> // update #2
> daoFactory.close();
>
> then update #2 is being committed.
>
> If I put in this in the close() method of my DAO Factory
>
> if (!this.dbConn.getAutoCommit()) {
> this.dbConn.rollback();
> }
>
> before the close() call, then update #2 is correctly not getting committed.
>
> I looked back through the recent tomcat changelogs, and found a
> reference to https://bz.apache.org/bugzilla/show_bug.cgi?id=61425
> under the 8.5.21 release which looks like it might be addressing this
> problem. However, when I download the source for 8.5.23, there is no
> org.apache.tomcat.jdbc directory so I can't dive in there.
>
> Anyone else experienced this? Hopefully I am just missing something
> obvious.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: Cluster StaticMember (McastService:Required property "tcpListenPort" is missing)

2017-08-21 Thread Keiichi Fujino
Hi

https://bz.apache.org/bugzilla/show_bug.cgi?id=61448#c2

2017-08-18 20:47 GMT+09:00 Carlos Peon Costa :

> Hello,
>
> It seems to me that it's always necessary to initialize
> membershipService, maybe something like that (untested):
>
> --- apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/
> group/ChannelCoordinator.java.original
> 2016-06-15 18:45:51.0 +0200
> +++ apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/
> group/ChannelCoordinator.java
>  2017-08-18 13:19:53.342672900 +0200
> @@ -148,6 +148,10 @@
>  }
>  clusterReceiver.start();
>  //synchronize, big time FIXME
> +
> membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
> +
> getClusterReceiver().getPort(),
> +
> getClusterReceiver().getSecurePort(),
> +
> getClusterReceiver().getUdpPort());
>  Member localMember = getChannel().getLocalMember(false);
>  if (localMember instanceof StaticMember) {
>  // static member
> @@ -155,13 +159,6 @@
>  staticMember.setHost(getClusterReceiver().getHost());
>  staticMember.setPort(getClusterReceiver().getPort());
>
> staticMember.setSecurePort(getClusterReceiver().getSecurePort());
> -} else {
> -// multicast member
> -
> membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
> -getClusterReceiver().getPort(),
> -getClusterReceiver().getSecurePort(),
> -getClusterReceiver().getUdpPort());
> -
>  }
>  valid = true;
>  }
>
> Regards,
> Carlos.
>
> On Fri, Aug 18, 2017 at 9:51 AM, Carlos Peon Costa 
> wrote:
> > The reason could be here:
> >
> > $ diff -r apache-tomcat-7.0.69-src/java/org/apache/catalina/tribes/
> group/ChannelCoordinator.java
> > apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/
> group/ChannelCoordinator.java
> > 146,149c151,165
> > < membershipService.setLocalMemberProperties(
> getClusterReceiver().getHost(),
> > <
>   getClusterReceiver().getPort(),
> > <
>   getClusterReceiver().getSecurePort(),
> > <
>   getClusterReceiver().getUdpPort());
> > ---
> >> Member localMember = getChannel().getLocalMember(
> false);
> >> if (localMember instanceof StaticMember) {
> >> // static member
> >> StaticMember staticMember =
> (StaticMember)localMember;
> >> staticMember.setHost(getClusterReceiver().getHost()
> );
> >> staticMember.setPort(getClusterReceiver().getPort()
> );
> >> staticMember.setSecurePort(getClusterReceiver().
> getSecurePort());
> >> } else {
> >> // multicast member
> >> membershipService.setLocalMemberProperties(
> getClusterReceiver().getHost(),
> >> getClusterReceiver().getPort(),
> >> getClusterReceiver().getSecurePort(),
> >> getClusterReceiver().getUdpPort());
> >>
> >> }
> >
>



-- 
Keiichi.Fujino


Re: Problem with ServletContext replication

2017-03-01 Thread Keiichi Fujino
Hi.

This seems to ReplicatedContext's bug.
In the current code, the class loader is passed to ReplicationMap as Null.
It is necessary to call super.startInternal() before initializing the
ReplicationMap.

Please open bugzilla.

2017-03-02 10:15 GMT+09:00 Andrew Gillett :

> Environment:
>   Apache Tomcat 8.5.11
>   OpenJDK Runtime Environment (build 1.8.0_121-b13)
>
> Hi,
>
> I am trying to run a two node Tomcat cluster (server1 & server2) with
> an Apache load balancer.
> I require both Session and Context replication.
>
> I've had no trouble getting Session replication to work using
> SimpleTcpCluster, however I've been unable to get the Context
> replication to work.
>
> I have the following config in META-INF/context.xml:
> 
>
> and in WEB-INF/web.xml:
> 
>
> When I place an object in the server1 ServletContext I see the
> following error on server2:
>
> 02-Mar-2017 11:31:28.088 SEVERE
> [Tribes-Task-Receiver[Catalina-Channel]-3]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived
> Unable to deserialize MapMessage.
>  java.lang.ClassNotFoundException: com.pharmhos.merlin.jaas.AdUser
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at java.io.ObjectInputStream.resolveClass(
> ObjectInputStream.java:677)
> at org.apache.catalina.tribes.io.ReplicationStream.resolveClass(
> ReplicationStream.java:79)
> at java.io.ObjectInputStream.readNonProxyDesc(
> ObjectInputStream.java:1819)
> at java.io.ObjectInputStream.readClassDesc(
> ObjectInputStream.java:1713)
> at java.io.ObjectInputStream.readOrdinaryObject(
> ObjectInputStream.java:1986)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.
> java:1535)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.
> java:422)
> at org.apache.catalina.tribes.io.XByteBuffer.deserialize(
> XByteBuffer.java:558)
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap$
> MapMessage.value(AbstractReplicatedMap.java:1504)
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap$
> MapMessage.deserialize(AbstractReplicatedMap.java:1462)
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.
> messageReceived(AbstractReplicatedMap.java:649)
> at org.apache.catalina.tribes.group.GroupChannel.
> messageReceived(GroupChannel.java:300)
> at org.apache.catalina.tribes.group.ChannelInterceptorBase.
> messageReceived(ChannelInterceptorBase.java:83)
> at org.apache.catalina.tribes.group.ChannelInterceptorBase.
> messageReceived(ChannelInterceptorBase.java:83)
> at org.apache.catalina.tribes.group.interceptors.
> TcpFailureDetector.messageReceived(TcpFailureDetector.java:116)
> at org.apache.catalina.tribes.group.ChannelInterceptorBase.
> messageReceived(ChannelInterceptorBase.java:83)
> at org.apache.catalina.tribes.group.ChannelCoordinator.
> messageReceived(ChannelCoordinator.java:276)
> at org.apache.catalina.tribes.transport.ReceiverBase.
> messageDataReceived(ReceiverBase.java:244)
> at org.apache.catalina.tribes.transport.nio.NioReplicationTask.
> drainChannel(NioReplicationTask.java:213)
> at org.apache.catalina.tribes.transport.nio.
> NioReplicationTask.run(NioReplicationTask.java:101)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> It appears that my AdUser object is being serialized on server1 but is
> not being deserialized on server2.
>
> The "AdUser" class exists within the web application under
> WEB-INF/classes but it looks like the
> org.apache.catalina.tribes.io.ReplicationStream is not using the right
> class loader for the web app.
>
> I don't know if this is a configuration error, tomcat bug, or
> something else.  Any suggestions on how to diagnose or resolve this
> issue will be gratefully received.
>
>
> Andrew gillett
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
2017-02-09 18:45 GMT+09:00 Fady Haikal :

> i will try that but this required tomcat restart so i will be
> scheduling tonight a restart, anyway from where i can enable the
> org.apache.catalina.tribes.MESSAGES i didn't found it in the
> logging.properties file
>


The org.apache.catalina.tribes.MESSAGES is the logger name.
You have to add settings to the logging.properties file.
The following is a sample. Please refer to.

Note for using the org.apache.catalina.tribes.MESSAGES:
The org.apache.catalina.tribes.MESSAGES outputs a lot of trace level logs.
So It should get logs in a short period of time.

=
handlers = 1catalina.org.apache.juli.AsyncFileHandler,
2localhost.org.apache.juli.AsyncFileHandler,
3manager.org.apache.juli.AsyncFileHandler,
4host-manager.org.apache.juli.AsyncFileHandler,
java.util.logging.ConsoleHandler,
10catalina.org.apache.juli.AsyncFileHandler

//omit

# FOR DEBUG
10catalina.org.apache.juli.AsyncFileHandler.formatter =
org.apache.juli.VerbatimFormatter
10catalina.org.apache.juli.AsyncFileHandler.level = FINEST
10catalina.org.apache.juli.AsyncFileHandler.directory =
${catalina.base}/logs
10catalina.org.apache.juli.AsyncFileHandler.prefix = MESSAGES.
10catalina.org.apache.juli.AsyncFileHandler.bufferSize = -1
org.apache.catalina.tribes.MESSAGES.level = FINEST
org.apache.catalina.tribes.MESSAGES.handlers =
10catalina.org.apache.juli.AsyncFileHandler



> On Thu, Feb 9, 2017 at 11:40 AM, Keiichi Fujino 
> wrote:
> > Hi
> >
> > Please try mapSendOptions = 8.
> > This means that it does not receive ACK of the messages.
> > Processing is returned immediately after message transmission is
> completed.
> >
> > As another way,
> > Please try the org.apache.catalina.tribes.MESSAGES. (see previous my
> > response mail.)
> >
> >
> >
> > 2017-02-09 18:23 GMT+09:00 Fady Haikal :
> >
> >> The  is set under the context.xml
> >>
> >>  >>    notifyListenersOnReplication="true"
> >>mapSendOptions="6"/>
> >>
> >> On Thu, Feb 9, 2017 at 11:21 AM, Keiichi Fujino 
> >> wrote:
> >> > 2017-02-09 18:10 GMT+09:00 Fady Haikal :
> >> >
> >> >> Keiichi,
> >> >> mapSendoption is not configured anyway please check my configuration
> >> below
> >> >>
> >> >
> >> >
> >> > You have not set .
> >> > If you do not use Cluster Manager template, DeltaManager is used by
> >> default.
> >> > However, in the logs, it seems to be using BackupManager.
> >> > Have you set  in webapps/{your app}
> >> /META-INF/context.xml
> >> > or conf/{Engine}/{Host}/{your app}.xml?
> >> >
> >> >
> >> >
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >>>> >> />
> >> >>   
> >> >>   
> >> >>>> >> SSLEngine="on" />
> >> >>   
> >> >>>> >> />
> >> >>>> >> />
> >> >>>> >> />
> >> >>
> >> >>   
> >> >>   
> >> >> 
> >> >>  >> >>   type="org.apache.catalina.UserDatabase"
> >> >>   description="User database that can be updated and
> saved"
> >> >>   factory="org.apache.catalina.users.
> >> >> MemoryUserDatabaseFactory"
> >> >>   pathname="conf/tomcat-users.xml" />
> >> >>   
> >> >>
> >> >>   
> >> >>   
> >> >>
> >> >> 
> >> >> 
> >> >>
> >> >>
> >> >> 
> >> >>  >> >>connectionTimeout="6" maxThreads="500"
> >> >> minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
> >> >> disableUploadTimeout="true" acceptCount="100" redirectPort="8443" />
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >>
> >> >> 
> >> >> 
> >> >>
> >> >>
> >> >> 
> >> >>
> >> >> 
> >> >>  >> >> jvmRoute="TomcatNode1">
> &

Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
2017-02-09 19:21 GMT+09:00 Fady Haikal :

> i already restarted it after changing the parameter to 8
>

However, I can not see the log that context has been restarted in the log
you showed.
You may need to restart Tomcat.



>
> On Thu, Feb 9, 2017 at 12:16 PM, Keiichi Fujino 
> wrote:
> > It is realy strange.
> > Have you failed to restart Context?
> > When starting up the AbstractReplicatedMap, the followings should be
> logged.
> >
> > "Initializing AbstractReplicatedMap with context name:xxx"
> > "AbstractReplicatedMap[xxx] initialization was completed in xxx ms."
> >
> >
> > 2017-02-09 19:09 GMT+09:00 Fady Haikal :
> >
> >> i can only see this error related to AbstractReplicatedMap
> >>
> >>
> >> 09-Feb-2017 12:44:12.676 SEVERE [GroupChannel-Heartbeat-1]
> >> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat
> >> Unable to send AbstractReplicatedMap.ping message
> >>  java.lang.NullPointerException
> >> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.
> >> ping(AbstractReplicatedMap.java:256)
> >> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat(
> >> AbstractReplicatedMap.java:885)
> >> at org.apache.catalina.tribes.group.GroupChannel.heartbeat(
> >> GroupChannel.java:166)
> >> at org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(
> >> GroupChannel.java:697)
> >>
> >> On Thu, Feb 9, 2017 at 12:04 PM, Keiichi Fujino 
> >> wrote:
> >> > These logs seem to be the tomcat memory leak detections logs during
> >> context
> >> > restart.
> >> > It is a different issue from this thread's topic.
> >> >
> >> > Anyway, Can you see the log likea "AbstractReplicatedMap[xxx]
> >> > initialization was completed in xxx ms." in your log file?
> >> >
> >> > 2017-02-09 18:49 GMT+09:00 Fady Haikal :
> >> >
> >> >> Keiichi,
> >> >> once i changed the mapSendOptions and without restarting the below
> >> >> shown in the tomcat
> >> >>
> >> >>
> >> >> 09-Feb-2017 12:44:12.299 SEVERE
> >> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> >> checkThreadLocalMapForLeaks
> >> >> The web application [imal_services] created a ThreadLocal with key of
> >> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value
> of
> >> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> >> >> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> >> >> was stopped. Threads are going to be renewed over time to try and
> >> >> avoid a probable memory leak.
> >> >> 09-Feb-2017 12:44:12.300 SEVERE
> >> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> >> checkThreadLocalMapForLeaks
> >> >> The web application [imal_services] created a ThreadLocal with key of
> >> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value
> of
> >> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  A.ALMANA
> >> >> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> >> >> was stopped. Threads are going to be renewed over time to try and
> >> >> avoid a probable memory leak.
> >> >> 09-Feb-2017 12:44:12.300 SEVERE
> >> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> >> checkThreadLocalMapForLeaks
> >> >> The web application [imal_services] created a ThreadLocal with key of
> >> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value
> of
> >> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> >> >> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> >> >> was stopped. Threads are going to be renewed over time to try and
> >> >> avoid a probable memory leak.
> >> >> 09-Feb-2017 12:44:12.301 SE

Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
It is realy strange.
Have you failed to restart Context?
When starting up the AbstractReplicatedMap, the followings should be logged.

"Initializing AbstractReplicatedMap with context name:xxx"
"AbstractReplicatedMap[xxx] initialization was completed in xxx ms."


2017-02-09 19:09 GMT+09:00 Fady Haikal :

> i can only see this error related to AbstractReplicatedMap
>
>
> 09-Feb-2017 12:44:12.676 SEVERE [GroupChannel-Heartbeat-1]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat
> Unable to send AbstractReplicatedMap.ping message
>  java.lang.NullPointerException
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.
> ping(AbstractReplicatedMap.java:256)
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat(
> AbstractReplicatedMap.java:885)
> at org.apache.catalina.tribes.group.GroupChannel.heartbeat(
> GroupChannel.java:166)
> at org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(
> GroupChannel.java:697)
>
> On Thu, Feb 9, 2017 at 12:04 PM, Keiichi Fujino 
> wrote:
> > These logs seem to be the tomcat memory leak detections logs during
> context
> > restart.
> > It is a different issue from this thread's topic.
> >
> > Anyway, Can you see the log likea "AbstractReplicatedMap[xxx]
> > initialization was completed in xxx ms." in your log file?
> >
> > 2017-02-09 18:49 GMT+09:00 Fady Haikal :
> >
> >> Keiichi,
> >> once i changed the mapSendOptions and without restarting the below
> >> shown in the tomcat
> >>
> >>
> >> 09-Feb-2017 12:44:12.299 SEVERE
> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> checkThreadLocalMapForLeaks
> >> The web application [imal_services] created a ThreadLocal with key of
> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> >> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> >> was stopped. Threads are going to be renewed over time to try and
> >> avoid a probable memory leak.
> >> 09-Feb-2017 12:44:12.300 SEVERE
> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> checkThreadLocalMapForLeaks
> >> The web application [imal_services] created a ThreadLocal with key of
> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  A.ALMANA
> >> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> >> was stopped. Threads are going to be renewed over time to try and
> >> avoid a probable memory leak.
> >> 09-Feb-2017 12:44:12.300 SEVERE
> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> checkThreadLocalMapForLeaks
> >> The web application [imal_services] created a ThreadLocal with key of
> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> >> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> >> was stopped. Threads are going to be renewed over time to try and
> >> avoid a probable memory leak.
> >> 09-Feb-2017 12:44:12.301 SEVERE
> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> checkThreadLocalMapForLeaks
> >> The web application [imal_services] created a ThreadLocal with key of
> >> type [com.path.lib.common.util.ThreadAttributes$1] (value
> >> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> >> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.SHAIKH  LOGOUT
> >> Process}]) but failed to remove it when the web application was
> >> stopped. Threads are going to be renewed over time to try and avoid a
> >> probable memory leak.
> >> 09-Feb-2017 12:44:12.301 SEVERE
> >> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> >> org.apache.catalina.loader.WebappClassLoaderBase.
> >> checkThreadLocalMapForLeaks
> >> The web application [imal_services] created a ThreadLocal with key of
> >> type [co

Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
These logs seem to be the tomcat memory leak detections logs during context
restart.
It is a different issue from this thread's topic.

Anyway, Can you see the log likea "AbstractReplicatedMap[xxx]
initialization was completed in xxx ms." in your log file?

2017-02-09 18:49 GMT+09:00 Fady Haikal :

> Keiichi,
> once i changed the mapSendOptions and without restarting the below
> shown in the tomcat
>
>
> 09-Feb-2017 12:44:12.299 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> was stopped. Threads are going to be renewed over time to try and
> avoid a probable memory leak.
> 09-Feb-2017 12:44:12.300 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  A.ALMANA
> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> was stopped. Threads are going to be renewed over time to try and
> avoid a probable memory leak.
> 09-Feb-2017 12:44:12.300 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> was stopped. Threads are going to be renewed over time to try and
> avoid a probable memory leak.
> 09-Feb-2017 12:44:12.301 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.SHAIKH  LOGOUT
> Process}]) but failed to remove it when the web application was
> stopped. Threads are going to be renewed over time to try and avoid a
> probable memory leak.
> 09-Feb-2017 12:44:12.301 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> was stopped. Threads are going to be renewed over time to try and
> avoid a probable memory leak.
> 09-Feb-2017 12:44:12.302 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> was stopped. Threads are going to be renewed over time to try and
> avoid a probable memory leak.
> 09-Feb-2017 12:44:12.303 SEVERE
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]]
> org.apache.catalina.loader.WebappClassLoaderBase.
> checkThreadLocalMapForLeaks
> The web application [imal_services] created a ThreadLocal with key of
> type [com.path.lib.common.util.ThreadAttributes$1] (value
> [com.path.lib.common.util.ThreadAttributes$1@6ca9b927]) and a value of
> type [java.util.HashMap] (value [{PATH_INFO=IBIS  M.HANAFI
> UNKNOWN_PROG_REF}]) but failed to remove it when the web application
> was stopped. Threads are going to be renewed over time to try and
> avoid a probable memory leak.
> 09-Feb-2017 12:44:12.676 SEVERE [GroupChannel-Heartbeat-1]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat
> Unable to send AbstractReplicatedMap.ping message
>  java.lang.NullPointerException
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.
> ping(AbstractReplicatedMap.java:2

Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
Hi

Please try mapSendOptions = 8.
This means that it does not receive ACK of the messages.
Processing is returned immediately after message transmission is completed.

As another way,
Please try the org.apache.catalina.tribes.MESSAGES. (see previous my
response mail.)



2017-02-09 18:23 GMT+09:00 Fady Haikal :

> The  is set under the context.xml
>
> notifyListenersOnReplication="true"
>mapSendOptions="6"/>
>
> On Thu, Feb 9, 2017 at 11:21 AM, Keiichi Fujino 
> wrote:
> > 2017-02-09 18:10 GMT+09:00 Fady Haikal :
> >
> >> Keiichi,
> >> mapSendoption is not configured anyway please check my configuration
> below
> >>
> >
> >
> > You have not set .
> > If you do not use Cluster Manager template, DeltaManager is used by
> default.
> > However, in the logs, it seems to be using BackupManager.
> > Have you set  in webapps/{your app}
> /META-INF/context.xml
> > or conf/{Engine}/{Host}/{your app}.xml?
> >
> >
> >
> >> 
> >> 
> >> 
> >> 
> >>>> />
> >>   
> >>   
> >>>> SSLEngine="on" />
> >>   
> >>>> />
> >>>> />
> >>>> />
> >>
> >>   
> >>   
> >> 
> >>  >>   type="org.apache.catalina.UserDatabase"
> >>   description="User database that can be updated and saved"
> >>   factory="org.apache.catalina.users.
> >> MemoryUserDatabaseFactory"
> >>   pathname="conf/tomcat-users.xml" />
> >>   
> >>
> >>   
> >>   
> >>
> >> 
> >> 
> >>
> >>
> >> 
> >>  >>connectionTimeout="6" maxThreads="500"
> >> minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
> >> disableUploadTimeout="true" acceptCount="100" redirectPort="8443" />
> >> 
> >> 
> >> 
> >> 
> >>
> >> 
> >> 
> >>
> >>
> >> 
> >>
> >> 
> >>  >> jvmRoute="TomcatNode1">
> >>   
> >>   
> >> 
> >>  >>resourceName="UserDatabase"/>
> >>   
> >>
> >>>> unpackWARs="true" autoDeploy="true" startStopThreads="0">
> >>   
> >>   
> >>
> >>   >>  channelSendOptions="4">
> >>   
> >>  >> className="org.apache.catalina.tribes.membership.McastService"
> >> address="228.0.0.4"
> >> port="45560"
> >> frequency="500"
> >> dropTime="9000"/>
> >>  >> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> >>   address="auto"
> >>   port="4000"
> >>   autoBind="100"
> >>   selectorTimeout="5000"
> >>   maxThreads="6"/>
> >>
> >>  >> className="org.apache.catalina.tribes.transport.
> ReplicationTransmitter">
> >>>> className="org.apache.catalina.tribes.transport.nio.
> >> PooledParallelSender"/>
> >> 
> >>  >> className="org.apache.catalina.tribes.group.interceptors.
> >> TcpFailureDetector"/>
> >>  >> className="org.apache.catalina.tribes.group.interceptors.
> >> MessageDispatch15Interceptor"/>
> >>   
> >>
> >>>>
> >> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.
> >> *\.html|.*\.css|.*\.txt"/>
> >>>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
> >>
> >>>> tempDir="D:/imaljava/TomcatNode1/tmp/war-temp/"
> >> dep

Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
2017-02-09 18:10 GMT+09:00 Fady Haikal :

> Keiichi,
> mapSendoption is not configured anyway please check my configuration below
>


You have not set .
If you do not use Cluster Manager template, DeltaManager is used by default.
However, in the logs, it seems to be using BackupManager.
Have you set  in webapps/{your app} /META-INF/context.xml
or conf/{Engine}/{Host}/{your app}.xml?



> 
> 
> 
> 
>/>
>   
>   
>SSLEngine="on" />
>   
>/>
>/>
>/>
>
>   
>   
> 
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.
> MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>   
>
>   
>   
>
> 
> 
>
>
> 
> connectionTimeout="6" maxThreads="500"
> minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
> disableUploadTimeout="true" acceptCount="100" redirectPort="8443" />
> 
> 
> 
> 
>
> 
> 
>
>
> 
>
> 
>  jvmRoute="TomcatNode1">
>   
>   
> 
> resourceName="UserDatabase"/>
>   
>
>unpackWARs="true" autoDeploy="true" startStopThreads="0">
>   
>   
>
>channelSendOptions="4">
>   
>  className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45560"
> frequency="500"
> dropTime="9000"/>
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   address="auto"
>   port="4000"
>   autoBind="100"
>   selectorTimeout="5000"
>   maxThreads="6"/>
>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>className="org.apache.catalina.tribes.transport.nio.
> PooledParallelSender"/>
> 
>  className="org.apache.catalina.tribes.group.interceptors.
> TcpFailureDetector"/>
>  className="org.apache.catalina.tribes.group.interceptors.
> MessageDispatch15Interceptor"/>
>   
>
>   
> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.
> *\.html|.*\.css|.*\.txt"/>
>className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>tempDir="D:/imaljava/TomcatNode1/tmp/war-temp/"
> deployDir="D:/imaljava/TomcatNode1/tmp/war-deploy/"
> watchDir="D:/imaljava/TomcatNode1/tmp/war-listen/"
> watchEnabled="false"/>
>
>className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> 
> 
> 
>
> 
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t "%r" %s %b" />
>   threshold="900" />
>
>   
> 
>   
> 
>
>
> On Thu, Feb 9, 2017 at 10:32 AM, Keiichi Fujino 
> wrote:
> > Hi
> >
> > You seems to be using BackupManager.
> > What is set for mapSendOptions?
> >
> > The Cluster module uses the Tomcat JULI logging FW,
> > so you can enable logging on the org.apache.catalina.tribes.MESSAGES,
> you
> > can track messages.
> >
> > Note for using the org.apache.catalina.tribes.MESSAGES:
> > The org.apache.catalina.tribes.MESSAGES outputs a lot of trace level
> logs.
> > So It should get logs in a short period of time.
> >
> >
> > 2017-02-06 15:52 GMT+09:00 Fady Haikal :
> >
> >> Guys, we are facing the below errors in Tomcat cluster, please advise
> >>
> >>
> >> 06-Feb-2017 01:14:20.718 SEVERE [GroupChannel-Heartbeat-1]
> >> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat
> >> Unable to send AbstractReplicatedMap.ping message
> >>  org

Re: Operation has timed out

2017-02-09 Thread Keiichi Fujino
Hi

You seems to be using BackupManager.
What is set for mapSendOptions?

The Cluster module uses the Tomcat JULI logging FW,
so you can enable logging on the org.apache.catalina.tribes.MESSAGES, you
can track messages.

Note for using the org.apache.catalina.tribes.MESSAGES:
The org.apache.catalina.tribes.MESSAGES outputs a lot of trace level logs.
So It should get logs in a short period of time.


2017-02-06 15:52 GMT+09:00 Fady Haikal :

> Guys, we are facing the below errors in Tomcat cluster, please advise
>
>
> 06-Feb-2017 01:14:20.718 SEVERE [GroupChannel-Heartbeat-1]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat
> Unable to send AbstractReplicatedMap.ping message
>  org.apache.catalina.tribes.ChannelException: Operation has timed
> out(3000 ms.).; Faulty members:tcp://{10, 114, 43, 103}:4000;
> at org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage(
> ParallelNioSender.java:108)
> at org.apache.catalina.tribes.transport.nio.PooledParallelSender.
> sendMessage(PooledParallelSender.java:48)
> at org.apache.catalina.tribes.transport.ReplicationTransmitter.
> sendMessage(ReplicationTransmitter.java:54)
> at org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage(
> ChannelCoordinator.java:82)
> at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(
> ChannelInterceptorBase.java:76)
> at org.apache.catalina.tribes.group.interceptors.
> MessageDispatchInterceptor.sendMessage(MessageDispatchInterceptor.java:81)
> at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(
> ChannelInterceptorBase.java:76)
> at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.
> sendMessage(TcpFailureDetector.java:93)
> at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(
> ChannelInterceptorBase.java:76)
> at org.apache.catalina.tribes.group.GroupChannel.send(
> GroupChannel.java:233)
> at org.apache.catalina.tribes.group.GroupChannel.send(
> GroupChannel.java:186)
> at org.apache.catalina.tribes.group.RpcChannel.send(RpcChannel.java:99)
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.
> ping(AbstractReplicatedMap.java:267)
> at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.heartbeat(
> AbstractReplicatedMap.java:885)
> at org.apache.catalina.tribes.group.GroupChannel.heartbeat(
> GroupChannel.java:161)
> at org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(
> GroupChannel.java:697)
>
>
> 06-Feb-2017 01:20:51.437 SEVERE [NioReceiver]
> org.apache.catalina.tribes.transport.nio.NioReceiver.listen Unable to
> process request in NioReceiver
>  java.io.IOException: A non-blocking socket operation could not be
> completed immediately
> at sun.nio.ch.SocketDispatcher.close0(Native Method)
> at sun.nio.ch.SocketDispatcher.close(Unknown Source)
> at sun.nio.ch.SocketChannelImpl.kill(Unknown Source)
> at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
> at sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown Source)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
> at sun.nio.ch.SelectorImpl.select(Unknown Source)
> at org.apache.catalina.tribes.transport.nio.NioReceiver.
> listen(NioReceiver.java:272)
> at org.apache.catalina.tribes.transport.nio.NioReceiver.run(
> NioReceiver.java:425)
> at java.lang.Thread.run(Unknown Source)
>
> Regards,
> Fady
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Keiichi.Fujino


Re: TomcatCon @ ApacheCon

2017-02-06 Thread Keiichi Fujino
Hi,

I've submitted a proposal for Tomcat Clustering.
http://events.linuxfoundation.org/cfp/proposals/6216/13474



> --
> Keiichi.Fujino
> 
> 
>


Re: Question about suspectTimeout property of pool configuration - possible Bug - does only work with removeAbandoned = true which seems odd

2016-08-23 Thread Keiichi Fujino
2016-08-19 0:52 GMT+09:00 Torsten Krah :

> Hi,
>
> looking at the doc:
>
> https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
>
> there is:
>
> suspectTimeout
>
> (int) Timeout value in seconds. Default value is 0.
> Similar to to the removeAbandonedTimeout value but instead of treating
> the connection as abandoned, and potentially closing the connection,
> this simply logs the warning if logAbandoned is set to true. If this
> value is equal or less than 0, no suspect checking will be performed.
> Suspect checking only takes place if the timeout value is larger than 0
> and the connection was not abandoned or if abandon check is disabled. If
> a connection is suspect a WARN message gets logged and a JMX
> notification gets sent once.
>
> To me this sounds like i should get a warning if i configure the pool
> like this:
>
>  logAbandoned="true"
>  suspectTimeout="120"
>
> after 2 minutes.
> I don't want to remove the connections, i just want to get them logged.
>
> However i don't see such messages - looking at the code it seems that
> suspect() from the connection is called from the pool in:
>
> pool.checkAbandoned();
>
> but this is only called from the PoolCleaner in its run method when the
> check:
>
> if (pool.getPoolProperties().isRemoveAbandoned())
> pool.checkAbandoned();
>
> is true.
> But i don't want to get them removed - i just want them logged like
> suspect is promising - at least it sounds to me like that.
>
> Any thoughts about that? Shouldn't it read like:
>
> if (pool.getPoolProperties().isRemoveAbandoned() ||
> pool.getPoolProperties().getSuspectTimeout() > 0)
> pool.checkAbandoned();
>
> JavaDoc of setSuspectTimeout:
>
> /**
>  * Similar to {@link #setRemoveAbandonedTimeout(int)} but instead of
> treating the connection
>  * as abandoned, and potentially closing the connection, this simply
> logs the warning if
>  * {@link #isLogAbandoned()} returns true. If this value is equal or
> less than 0, no suspect
>  * checking will be performed. Suspect checking only takes place if
> the timeout value is larger than 0 and
>  * the connection was not abandoned or if abandon check is disabled.
> If a connection is suspect a WARN message gets
>  * logged and a JMX notification gets sent once.
>  * @param seconds - the amount of time in seconds that has to pass
> before a connection is marked suspect.
>  */
> public void setSuspectTimeout(int seconds);
>
>
> does also imply this behaviour i would expect.
> It seems you need to remove them (even with a large timeout set to get
> suspect working) - javadoc reads i can have suspect without remove.
> If this should be the case checkAbandoned() needs some work so that
> shouldAbandon() does check the property - removeAbandoned - to make sure
> it should really remove it, not just got to suspect in the else case -
> or just have to methods ... don't mind which solution, something like
> this ;).
>
> Should i open some ticket about that possible Bug or is it working as
> intended?
>
>
Hello Torsten

I'm not sure whether this is a bug.
However, I prefer the suspectTimeout does not depend on the removeAbandoned.
The suspectTimeout should work without abandoned connection.

Please open the bugzilla.




> kind regards
>
> Torsten
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: Problem with Cluster after upgrade to Tomcat 8.0.36.

2016-08-02 Thread Keiichi Fujino
2016-08-01 22:48 GMT+09:00 false :

> Hi all.
>
> Tomcat-8.0.36; JDK 1.8.0_102; CentOS 6.8. After upgrade from 8.0.28 to
> 8.0.36 I have problem with my cluster. I use static membership cluster with
> two nodes with BackupManager. After update I have errors in default.log:
> "WARN  org.apache.catalina.tribes.tipis.AbstractReplicatedMap - Notified
> member is not registered in the membership", but all works fine (packets
> exchanging between two nodes on tcp/4000). This message gone only if set
> default channelStartOptions (enable multicast), but not
> channelStartOptions="3". I try to downgrade version of Tomcat and this
> problem are not present in tomcat < 8.0.30.
>
> My config works a few years w/out problems.
>
> server.xml:
>
> ...
>   channelSendOptions="8"
>  channelStartOptions="3">
>
>  className="org.apache.catalina.ha.session.BackupManager"
>  expireSessionsOnShutdown="false"
>  notifyListenersOnReplication="true"
>  mapSendOptions="6"/>
> ...
>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>  className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
>timeout="5000"/>
> 
>  className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"/>
>  className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> 
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>
> 
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
>  className="org.apache.catalina.tribes.membership.StaticMember"
> port="4000"
> securePort="-1"
> host="${catalina.cluster.member.host}"
> domain="staging-cluster"
> uniqueId="{${
> catalina.cluster.member.unique.id}}"
> />
> 
>
>
Hi.

You can define the  in order to avoid this warning log.
 -
http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-interceptor.html#Static_Membership
 -
http://tomcat.apache.org/tomcat-8.0-doc/config/cluster-interceptor.html#Nested_Components

In more detail,
This is the side effects caused by r1716305 and r1716327.
Actually, this warning log does not result in much of a problem because the
replicationMap can build the appropriate membership by the ping mesage.
I've already fixed this problem at r1720074.



> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: Viewing Tomcat DB connection statement cache size via JMX MBeans

2016-07-03 Thread Keiichi Fujino
2016-07-01 13:18 GMT+09:00 Manisha Sapiah :

> Hi,
>
> I want to know, is there any way to get Tomcat DB connection statement
> cache size via JMX MBeans. Thanks in advance.
>
>
Which DB Connnection Pool do you use? DBCP or Tomcat jdbc-pool.
If you use the Tomcat jdbc-pool, such a feature does not exist.
The StatementCache Interceptor does not have MBean information.
If you need this feature, it needs to implement the MBean for
StatementCache Interceptor.



> Manisha
>
> --
> Keiichi.Fujino
>


Re: tomcat 7 connection pool validation interval

2016-07-03 Thread Keiichi Fujino
2016-06-30 23:32 GMT+09:00 Nir Dweck :

> I am using tomcat connection  pool (tomcat 7) in my application (java
> application) to connect to a remote Oracle DB on an Azure machine. My
> connection pool configuration is as follow:
>
> PoolProperties p = new PoolProperties();
> p.setUrl(connString);
> p.setUsername(user);
> p.setPassword(password);
> p.setDriverClassName("oracle.jdbc.OracleDriver");
> p.setValidationQuery("SELECT 1 from dual");
> p.setValidationInterval(1 * 6/2);
> p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
> p.setTestOnBorrow(true);
> p.setTestWhileIdle(true);
> p.setMinIdle(10);
> p.setInitialSize(10);
> However looking at the capture file, I see that the connections are not
> checked every 30 seconds as I expected. One connection is checked
> correctly, the others are checked after 3 times the configuration (180
> second). then again only some of the connections are checked and after a
> while it seems to stable on twice the configuration period (every 60
> seconds).
>
> I tested it with different configured time and different pool size, all
> had a instability period in which each time only part of the connections
> were checked and eventually it stabled on checks of all the connections
> every twice the configured time.
> What am I missing?
> Thanks,
>

I reproduced this.

I found the following code in the
org.apache.tomcat.jdbc.pool.ConnectionPool.
===
protected static class PoolCleaner extends TimerTask {
// snip

@Override
public void run() {
ConnectionPool pool = this.pool.get();
if (pool == null) {
stopRunning();
} else if (!pool.isClosed() &&
(System.currentTimeMillis() - lastRun) > sleepTime) {
lastRun = System.currentTimeMillis();
try {
// snip
===
Regardless of the scheduled PoolCleaner, (System.currentTimeMillis() -
lastRun) > sleepTime) is called.

Since PoolCleaner has been scheduled by the Timer#scheduleAtFixedRate,
This code probably is necessary in order to avoid a continuous calling of
PoolCleaner when the previous task was delayed.
However, This code causes the unintended skip of PoolCleaner.

I plan to fix the followings if there is no objection.
-Remove the "System.currentTimeMillis() - lastRun) > sleepTime".
-The scheduleAtFixedRate method changes to the schedule method.




>
> Nir
>
> --
> Keiichi.Fujino
>


Re: tomcat cluster questions

2016-05-24 Thread Keiichi Fujino
Hi,

2016-05-23 18:56 GMT+09:00 Hans-Joachim Kliemeck <
hans-joachim.kliem...@hays.de>:

> Hey,
>
> > If you do not set the LocalMember,
> > the implementation class of local members will become MemberImpl rather
> than the StaticMember.
> > In addition, you can not explicitly specify the domain and the uniqueId
> of local member.
> > If you do not mind these, there is no problem if you do not set
> LocalMember.
>
> According to the configuration example, it is possible to set the
> uniqueid/domain. Could you clarify your statement?
> https://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html
>
>   className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
> className="org.apache.catalina.tribes.membership.StaticMember"
>   port="4000"
>   securePort="-1"
>   host="tomcat01.mydomain.com"
>   domain="staging-cluster"
>   uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,1}"/>
> className="org.apache.catalina.tribes.membership.StaticMember"
>   port="5678"
>   securePort="-1"
>   host="tomcat01.mydomain.com"
>   domain="staging-cluster"
>   uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/>
>  
>
>
>
If you explicitly define the  in server.xml,
You can define the domain and uniqueId. (As in the above example)
If you do not define a  in server.xml,
the local member is automatically generated by the multicast service.
(This multicast service is available even if you use a static cluster)
The domain of this local member is used the domain  that is defined by
multicast service.
The uniqueId is automatically generated in multicast service.




> > The heartbeat is chained.
> >
> Container->Cluster->channel->Interceptor(TcpPingInterceptor)->ChannelSender
> > When using a static membership, TcpPingInterceptor does the nodes
> failure detection.
> > Therefore, when using a static membership, TcpPingInterceptor is
> required.
> I understand the concept of this chain, but I want to understand WHY there
> are these 3 points to enable the heartbeat instead of a central one?
> I don’t see a reason to send the heartbeat on different levels of the
> chain.
>
>
Usually, The heartbeat is controlled by the Channel#heartbeat only.
If you want to do the heartbeat, you set true to Channel#heartbeat.
If you do not want to do the heartbeat, you set false to Channel#heartbeat.
Cluster#heartbeatBackgroundEnabled is set to true only if you want to do a
heartbeat by the container background thread
.
The default is false
If heartbeatBackgroundEnabled is true, Channel # heartbeat is forced to
false.
The useThread is set to true only if you want to send a PING in a different
period than the heartbeat of the channel.



> Regards
> Hajo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 
> 
>


Re: Tomcat session replikation reports: IllegalStateException: setAttribute: Session [..] has already been invalidated

2016-05-23 Thread Keiichi Fujino
Is the channelSendOptions default?
In DeltaManager,
when the session expired, if there is a change in the session, replicates
the attributes of session.
And then, replicates the invalidated of the session.
Usually, although this order is not reversed,
if you want to ensure this order, you can set the 6(sync + ACK).

Another point,
The sticky session is enabled?
If the sticky session is not enabled,
when accessing to the non-primary node, the access to an invalid session
will occur.


2016-05-21 5:08 GMT+09:00 Knut Sander :

> Hi!
>
> We are running Tomcat 7.0.68 with SimpleTcpCluster with two nodes on
> different hosts.
>
> server.xml:
> [..]
> 
>   
>   [..]
> 
> [..]
>
> Everything works fine, except the messages below in catalina.out.
>
> The problem seems to occur, if a session is modified and invalidated
> during the same request (which is quite common imho). The invalidation
> is replicated faster than the attribute deltas, so the second node
> processes the invalidation and cannot handle the session-attribute
> modification afterwards. It would be no problem to forget about the
> modifications, because the session is invalid.
> Just the reported exception is quite misleading and the not really
> helpful for monitoring the logs.
>
> Any suggestions? Did we miss something?
>
> Thanks in advance,
> Knut
>
> --- catalina.out ---
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.session.DeltaManager
> messageReceived
> FINE: Manager [localhost#/xxx]: Received SessionMessage of
> type=(SESSION-EXPIRED) from
> [org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, x, x,
> x}:4000,{10, x, x, x},4000, alive=943161, securePort=-1, UDP Port=-1,
> id={25 ... -60 }, payload={}, command={}, domain={}, ]]
>
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.session.DeltaManager
> handleSESSION_EXPIRED
> FINE: Manager [localhost#/xxx]: received session
> [012F517D98B33DC5EB3F8CD488558BED] expired.
>
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> messageReceived
> FINE: Assuming clocks are synched: Replication for
> E43557F686529DC080B27BBB8FF52E6E-1463160674477 took=1 ms.
>
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.session.DeltaManager
> messageReceived
> FINE: Manager [localhost#/xxx]: Received SessionMessage of
> type=(SESSION-MODIFIED) from
> [org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, x, x,
> x}:4000,{10, x, x, x},4000, alive=943161, securePort=-1, UDP Port=-1,
> id={25 ... -60 }, payload={}, command={}, domain={}, ]]
>
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.session.DeltaManager
> handleSESSION_CREATED
> FINE: Manager [localhost#/xxx]: received session
> [E43557F686529DC080B27BBB8FF52E6E] created.
>
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.session.DeltaRequest execute
> FINER: Session.setAttribute('xxx', 'yyy')
>
> May 13, 2016 7:31:14 PM org.apache.catalina.ha.session.DeltaManager
> messageReceived
> SEVERE: Manager [localhost#/xxx]: Unable to receive message through TCP
> channel
> java.lang.IllegalStateException: setAttribute: Session
> [012F517D98B33DC5EB3F8CD488558BED] has already been invalidated
> at
>
> org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1447)
> at
>
> org.apache.catalina.ha.session.DeltaSession.setAttribute(DeltaSession.java:697)
> at
> org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:179)
> at
>
> org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1221)
> at
>
> org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1167)
> at
>
> org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:918)
> at
>
> org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:91)
> at
>
> org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:937)
> at
>
> org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:918)
> at
>
> org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:278)
> at
>
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
> at
>
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
> at
>
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:117)
> at
>
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:82)
> at
>
> org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:252)
> at
>
> org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:287)
> at
>
> org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:210)
> at
>
>

Re: tomcat cluster questions

2016-05-23 Thread Keiichi Fujino
2016-05-19 17:55 GMT+09:00 Hans-Joachim Kliemeck <
hans-joachim.kliem...@hays.de>:

> Hey,
>
> currently i'm building up a tomcat cluster and after studying the
> documentation/source some questions came up:
>
> Is it really necessary to add a LocalMember xml element to the
> StaticMembershipInterceptor?


If you do not set the LocalMember,
the implementation class of local members will become MemberImpl rather
than the StaticMember.
In addition, you can not explicitly specify the domain and the uniqueId of
local member.
If you do not mind these, there is no problem if you do not set LocalMember.



> I found a lot examples where this element was not added. FYI: we are using
> TCP and no Multicast.
>
>
This setting was introduced in r1714919,
it does not exist this setting in the examples that have been published
earlier.


> Why there are 3 points to configure a heartbeat? I don't see any reason
> for these three points, especially for TCP:
> heartbeat at channel object
> heartbeat at cluster object
> heartbeat at TcpPingInterceptor
>
>
The heartbeat is chained.
Container->Cluster->channel->Interceptor(TcpPingInterceptor)->ChannelSender
When using a static membership, TcpPingInterceptor does the nodes failure
detection.
Therefore, when using a static membership, TcpPingInterceptor is required.



> Kind Regards
> Hajo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: Session replication will never happen after disabling session persistence across Tomcat restarts

2016-04-24 Thread Keiichi Fujino
2016-04-23 15:29 GMT+09:00 sanigo :

> Hi!
>I have tested quite a few times to confirm that session replication
> will not happen after uncommenting  in
> conf/context.xml.
>If the line is commented out, the session replication will work
> happily.
>

Is there a warning message to your log files?
such as [Manager [xxx] does not implement ClusterManager, addition to
cluster has been aborted.]

if you have uncommented  in conf/context.xml,
All of the Web applications on your Tomcat use the StandardManager as a
session manager.
The StandardManager cannot replicate session.
If you want to replicate session, you have to use
ClusteManager(DeltaManager/BackupManager) as a session manager.
Usually defines a cluster manager template in the  / ,
and then it is cloned by distributable web application.




>The versions I have tested are 7.0.68 and 7.0.69.
>Any ideas?
> san...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: [Tomcat-JDBC] RemovedAbandoned doesn't trigger JdbcInterceptors

2015-12-17 Thread Keiichi Fujino
2015-12-17 22:25 GMT+09:00 Robert Anderson :

> Hi,
>
> When a connection is closed by "ResetAbandoned" the invoke() method from
> JdbcInterceptor is not called. Is it the expected behaviour?
>
>
Yes.

The JdbcInterceptor.invoke() method is not called when removeAbandoned.
The Connection(PooledConnection) is directly released without going through
the JdbcInterceptors.
(see PooledConnection.release())

If you want to capture the close of the connection,
you can use JdbcInterceptor.disconnected or reset (null, null).




> -->server.xml
>
> type="javax.sql.DataSource" removeAbandoned="true"
> removeAbandonedTimeout="30"
>maxActive="5" maxIdle="1"
> initialSize="0" minIdle="0" maxWait="5000"
>validationQuery="select 1"
>maxAge="1"
>testOnBorrow="true"
>factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>alternateUsernameAllowed="true"
>  jdbcInterceptors="pool.ExampleInterceptor"
>username="tomcat" password="example"
> driverClassName="com.intersys.jdbc.CacheDriver"
>url="jdbc:Cache://serverip:1972/NS"/>
>
> --> pool.ExampleInterceptor
>
> public class ExampleInterceptor extends JdbcInterceptor {
>
>
> public Object invoke(Object proxy, Method method, Object[] args) throws
> Throwable {
> if (method.getName() == CLOSE_VAL) {
> System.out.println("Interceptor called."); //Doesn't happen but
> connection is really closed (checked via JMX)
> }
> return super.invoke(proxy, method, args);
> }
>
> --> JSP to simulate long running query
>
> <%@ page session="false" import="java.sql.*,javax.naming.*, javax.sql.*,
> java.util.*" contentType="text/html" %><%
> Connection conn = null;
> try {
> Context ctx = new InitialContext();
> DataSource ds =
> (DataSource)ctx.lookup("java:comp/env/jdbc/cacheapp");
> conn = ds.getConnection();
> Thread.sleep(6);
> } catch (Exception e) {
> out.print(e.getMessage());
> } finally {
> if (conn != null) {
> try {
> //conn.close(); //Don't close to force
> RemovedAbandonedTimeout
> } catch (Exception e) {}
> }
> }
> %>
>
>
> Server version: Apache Tomcat/7.0.65
> Server built:   Oct 9 2015 08:36:58 UTC
> Server number:  7.0.65.0
> OS Name:Linux
> OS Version: 2.6.18-194.32.1.el5
> Architecture:   amd64
> JVM Version:1.7.0_80-b15
> JVM Vendor: Oracle Corporation
>
> Thanks in advance.
>
> P.S: Sorry, the subject was wrong.
>
> --
> Keiichi.Fujino
>


Re: [ANN] New committer: Martin Grigorov

2015-10-26 Thread Keiichi Fujino
2015-10-26 23:35 GMT+09:00 Mark Thomas :

> On behalf of the Tomcat committers I am pleased to announce that
> Martin Grigorov (mgrigorov) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
>

Welcome!



> Regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 




Re: Cluster - Session replication error: Unable to apply diff

2015-04-21 Thread Keiichi Fujino
Fixed at r1675020.

2015-04-20 16:18 GMT+09:00 Keiichi Fujino :

> This NPE has been caused by that apply the diff data to a
> ReplicatedMapEntry that has not set a MapOwner.
> Usually, ReplicatedMapEntry always has to have the MapOwner.
> I think this is probably a bug.
> Please open Bugzilla entry.
> I will scrutinize the code.
>
> 2015-04-20 15:04 GMT+09:00 Keiichi Fujino :
>
>> Hi
>>
>> Are there other error or exception in your log?
>>
>> Please show us your cluster configuration in your server.xml.
>> e.g.
>> - What is mapSendOptions?
>> - Which Interceptor do you use?
>>
>>
>>
>> 2015-04-15 3:55 GMT+09:00 Théo Chamley :
>>
>>> Hello,
>>>
>>> I have a working Tomcat 8.0.15 cluster with 3 members with the
>>> BackupManager as session manager.
>>> The session replication is mostly working except in a few cases. In
>>> those cases, I get the following error:
>>>
>>> 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6]
>>> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived
>>> Unable to apply diff to key:3B286B4C7CA060163A00988969D21923
>>>  java.lang.NullPointerException
>>> at
>>> org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164)
>>> at
>>> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664)
>>> at
>>> org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293)
>>> at
>>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>>> at
>>> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112)
>>> at
>>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>>> at
>>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>>> at
>>> org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89)
>>> at
>>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>>> at
>>> org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260)
>>> at
>>> org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240)
>>> at
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206)
>>> at
>>> org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>> I was able to replicate the problem with a scenario in the application,
>>> but I was not able to understand the underlying problem.
>>> This happens when the user is making a very specific request and this
>>> request arrives on a Tomcat where his session is not stored, forcing the
>>> Tomcat to fetch the session elsewhere.
>>>
>>> The 3 tomcats are on the same network with a very low network latency.
>>>
>>> Does anybody has some advice on how to debug this problem?
>>>
>>> For now, I got around it with sticky sessions on mod_jk, but I find this
>>> very unsatisfactory.
>>>
>>> Thank you in advance for your help,
>>>
>>> //Théo
>>>
>>> --
>>> Keiichi.Fujino
>>>
>>
>
>
> --
> Keiichi.Fujino
>



-- 
Keiichi.Fujino


Re: Cluster - Session replication error: Unable to apply diff

2015-04-20 Thread Keiichi Fujino
This NPE has been caused by that apply the diff data to a
ReplicatedMapEntry that has not set a MapOwner.
Usually, ReplicatedMapEntry always has to have the MapOwner.
I think this is probably a bug.
Please open Bugzilla entry.
I will scrutinize the code.

2015-04-20 15:04 GMT+09:00 Keiichi Fujino :

> Hi
>
> Are there other error or exception in your log?
>
> Please show us your cluster configuration in your server.xml.
> e.g.
> - What is mapSendOptions?
> - Which Interceptor do you use?
>
>
>
> 2015-04-15 3:55 GMT+09:00 Théo Chamley :
>
>> Hello,
>>
>> I have a working Tomcat 8.0.15 cluster with 3 members with the
>> BackupManager as session manager.
>> The session replication is mostly working except in a few cases. In those
>> cases, I get the following error:
>>
>> 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6]
>> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived
>> Unable to apply diff to key:3B286B4C7CA060163A00988969D21923
>>  java.lang.NullPointerException
>> at
>> org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164)
>> at
>> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664)
>> at
>> org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293)
>> at
>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>> at
>> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112)
>> at
>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>> at
>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>> at
>> org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89)
>> at
>> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
>> at
>> org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260)
>> at
>> org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240)
>> at
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206)
>> at
>> org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>> I was able to replicate the problem with a scenario in the application,
>> but I was not able to understand the underlying problem.
>> This happens when the user is making a very specific request and this
>> request arrives on a Tomcat where his session is not stored, forcing the
>> Tomcat to fetch the session elsewhere.
>>
>> The 3 tomcats are on the same network with a very low network latency.
>>
>> Does anybody has some advice on how to debug this problem?
>>
>> For now, I got around it with sticky sessions on mod_jk, but I find this
>> very unsatisfactory.
>>
>> Thank you in advance for your help,
>>
>> //Théo
>>
>> --
>> Keiichi.Fujino
>>
>


-- 
Keiichi.Fujino


Re: Cluster - Session replication error: Unable to apply diff

2015-04-19 Thread Keiichi Fujino
Hi

Are there other error or exception in your log?

Please show us your cluster configuration in your server.xml.
e.g.
- What is mapSendOptions?
- Which Interceptor do you use?



2015-04-15 3:55 GMT+09:00 Théo Chamley :

> Hello,
>
> I have a working Tomcat 8.0.15 cluster with 3 members with the
> BackupManager as session manager.
> The session replication is mostly working except in a few cases. In those
> cases, I get the following error:
>
> 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived
> Unable to apply diff to key:3B286B4C7CA060163A00988969D21923
>  java.lang.NullPointerException
> at
> org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164)
> at
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664)
> at
> org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
> at
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
> at
> org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81)
> at
> org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260)
> at
> org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240)
> at
> org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206)
> at
> org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>
> I was able to replicate the problem with a scenario in the application,
> but I was not able to understand the underlying problem.
> This happens when the user is making a very specific request and this
> request arrives on a Tomcat where his session is not stored, forcing the
> Tomcat to fetch the session elsewhere.
>
> The 3 tomcats are on the same network with a very low network latency.
>
> Does anybody has some advice on how to debug this problem?
>
> For now, I got around it with sticky sessions on mod_jk, but I find this
> very unsatisfactory.
>
> Thank you in advance for your help,
>
> //Théo
>
> --
> Keiichi.Fujino
>


Re: FarmWarDeployer via tomcat web manager

2015-04-14 Thread Keiichi Fujino
2015-04-14 15:58 GMT+09:00 :

> Keiichi Fujino  wrote on 14.04.2015 09:33:21:
>
> > From: Keiichi Fujino 
> > To: Tomcat Users List 
> > Date: 14.04.2015 09:33
> > Subject: Re: FarmWarDeployer via tomcat web manager
> >
> > 2015-04-14 14:22 GMT+09:00 :
> >
> > > "Caldarale, Charles R"  wrote on
> 14.04.2015
> > > 06:06:37:
> > >
> > > > From: "Caldarale, Charles R" 
> > > > To: Tomcat Users List 
> > > > Date: 14.04.2015 06:07
> > > > Subject: RE: FarmWarDeployer via tomcat web manager
> > > >
> > > > > From: Keiichi Fujino [mailto:kfuj...@apache.org]
> > > > > Subject: Re: FarmWarDeployer via tomcat web manager
> > > >
> > > > > > I changed war-listen path to webapps, and everything works fine
> > > untils I
> > > > > > restart my Tomcat 1 (master node).
> > > > > > After restarting tomcat my war file goes empty in webapps
> folder. (
> > > file
> > > > > > size 0). I saw that farmwardeployer run some kind of cleaning (
> or
> > > clear)
> > > > > > function.
> > > >
> > > > > Please show how to reproduce this in more detail.
> > > > > And attach your configuration(server.xml).
> > > >
> > > > Don't attach server.xml, since the list strips almost all
> > > > attachments.  Post it inline in the e-mail, with any sensitive
> > > > information obfuscated and preferably with comments removed.
> > > >
> > > >  - Chuck
> > > >
> > > Hi
> > > this is my server.xml from tomcat 1.
> > >
> > > 
> > >
> > > 
> > >className="org.apache.catalina.startup.VersionLoggerListener"
> > > />
> > >> > SSLEngine="on" />
> > >
> > >> > className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
> />
> > >> >
> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
> > >> > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
> />
> > >
> > >
> > >   
> > >
> > >  > >   type="org.apache.catalina.UserDatabase"
> > >   description="User database that can be updated and
> saved"
> > >  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> > >   pathname="conf/tomcat-users.xml" />
> > >   
> > >
> > > 
> > >
> > >
> > >  > >connectionTimeout="2"
> > >redirectPort="8443" />
> > >
> > > 
> > >
> > >
> > >  
> > >
> > >
> > >   > > unpackWARs="true" autoDeploy="false">
> > >
> > >  className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
> > > channelSendOptions="6">
> > >   > > className="org.apache.catalina.ha.session.DeltaManager"
> > >expireSessionsOnShutdown="false"
> > >notifyListenersOnReplication="true"/>
> > >
> > >
> > >> > className="org.apache.catalina.tribes.group.GroupChannel">
> > >  > > className="org.apache.catalina.tribes.membership.McastService"
> > > address="228.0.0.4"
> > > port="45564"
> > > frequency="500"
> > > dropTime="1"/>
> > >  > > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> > >   address="auto"
> > >   port="5000"
> > >   selectorTimeout="100"
> > >   maxThreads="6"/>
> > >
> > >  > >
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> > >> >
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> > > 
> > >  

Re: FarmWarDeployer via tomcat web manager

2015-04-13 Thread Keiichi Fujino
2015-04-14 14:22 GMT+09:00 :

> "Caldarale, Charles R"  wrote on 14.04.2015
> 06:06:37:
>
> > From: "Caldarale, Charles R" 
> > To: Tomcat Users List 
> > Date: 14.04.2015 06:07
> > Subject: RE: FarmWarDeployer via tomcat web manager
> >
> > > From: Keiichi Fujino [mailto:kfuj...@apache.org]
> > > Subject: Re: FarmWarDeployer via tomcat web manager
> >
> > > > I changed war-listen path to webapps, and everything works fine
> untils I
> > > > restart my Tomcat 1 (master node).
> > > > After restarting tomcat my war file goes empty in webapps folder. (
> file
> > > > size 0). I saw that farmwardeployer run some kind of cleaning ( or
> clear)
> > > > function.
> >
> > > Please show how to reproduce this in more detail.
> > > And attach your configuration(server.xml).
> >
> > Don't attach server.xml, since the list strips almost all
> > attachments.  Post it inline in the e-mail, with any sensitive
> > information obfuscated and preferably with comments removed.
> >
> >  - Chuck
> >
> Hi
> this is my server.xml from tomcat 1.
>
> 
>
> 
>/>
>SSLEngine="on" />
>
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>
>
>   
>
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>   
>
> 
>
>
> connectionTimeout="2"
>redirectPort="8443" />
>
> 
>
>
>  
>
>
>   unpackWARs="true" autoDeploy="false">
>
>  channelSendOptions="6">
>   className="org.apache.catalina.ha.session.DeltaManager"
>expireSessionsOnShutdown="false"
>notifyListenersOnReplication="true"/>
>
>
>className="org.apache.catalina.tribes.group.GroupChannel">
>  className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45564"
> frequency="500"
> dropTime="1"/>
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   address="auto"
>   port="5000"
>   selectorTimeout="100"
>   maxThreads="6"/>
>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> 
> 
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> 
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> 
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
>   
>   
>
> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
>
>className="org.apache.catalina.ha.deploy.FarmWarDeployer"
>  tempDir="/opt/tomcat/apache-tomcat-8.0.18/temp/war-temp/"
>

I think
The following configuration is not correct.


> deployDir="/opt/tomcat/apache-tomcat-8.0.18/webapps/"
>watchDir="/opt/tomcat/apache-tomcat-8.0.18/webapps/"
>


When deployDir and watchDir are set to the same value, FarmWarDeployer does
not work work properly.
(see FarmWarDeployer.copy).


-- 
> Keiichi.Fujino
>


Re: FarmWarDeployer via tomcat web manager

2015-04-13 Thread Keiichi Fujino
2015-04-13 18:42 GMT+09:00 :

> Hi
>
> I newbie on the Tomcat. I have HA architecture including Cisco ACE
> Loadbalancer, 3 servers with RHEL 7 + httpd 2.4 + mod_proxy AJP+ Tomcat
> 8.0.18.
>  I have problem with FarmWarDeployer. I would like to use FarmWarDeployer
> via Tomcat Web Manager. Is this possible?
>
>
No.
There is no such feature.


> I changed war-listen path to webapps, and everything works fine untils I
> restart my Tomcat 1 (master node).
> After restarting tomcat my war file goes empty in webapps folder. ( file
> size 0). I saw that farmwardeployer run some kind of cleaning ( or clear)
> function.
>
>
Please show how to reproduce this in more detail.
And attach your configuration(server.xml).



>
> Is it possible to stop clearing because everything else works fine and I
> like hot deployment via web manager.
>
> I'm trying to seek answer on web using google but nothing found.
>
> Thanx,
> Kimmo
>
> --
> Keiichi.Fujino
>


Re: Single Sign On Replication with New Tomcat Cluster Nodes

2014-12-09 Thread Keiichi Fujino
I examined the code of ClusterSingleSignOn.
This behavior seems to be bug.
There seems to be some other problems.
a) When a new node is started, SingleSignOnEntry of cache is not
replicated. (you mentioned.)
b) ClusterSingleSignOn does not implement ClusterValve.
c) Unsupported to BackupManager.
d) There are no documents.

In order to resolve this problem(a), it must be synchronized between
cluster nodes cache of SingleSignOnEntry at startup.
Please open a bug entry for a).

2014-12-05 3:35 GMT+09:00 Aaron R :

> Hello,
>
> I have a Tomcat cluster (7.0.42) that is configured to use the DeltaManager
> for session replication. It also uses the ClusterSingleSignOn valve for SSO
> and for propagating authentication to the other nodes in the cluster. If I
> log into Tomcat1, the session state and the single sign on state are
> successfully replicated to Tomcat2, so that when Tomcat1 goes down, the
> load balancer switches me to Tomcat2, and I am still authenticated and am
> able to access other applications on the server.
>
> The problem I'm having is that if a new node (Tomcat3) is then brought up
> after I have logged in, that new node does not appear to get any SSO state
> replicated to it, as I get a 403 error when trying to access a different
> application on the server. The regular session state is correctly
> replicated to it, but I don't seem to have SSO authentication on this new
> server.
>
> Should this scenario work? Is it possible to get the single sign on state
> propagated to nodes that come online after the user has logged in?
>
> I see one instance of someone mentioning a similar issue in passing a while
> back (
>
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200809.mbox/%3C15060d5e0809211745s522af93bv153367d9183c6e5e%40mail.gmail.com%3E
> ),
> but I didn't see any followup after that.
>
> Thanks,
> Aaron
>
> --
> Keiichi.Fujino
>


Re: [ANN] New committer: Felix Schumacher

2014-09-21 Thread Keiichi Fujino
Welcome! Enjoy!


2014-09-19 16:49 GMT+09:00 Rainer Jung :

> On behalf of the Tomcat committers I am pleased to announce that
> Felix Schumacher (fschumacher) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino 


Re: clustermembers don't detect shutdown of other members

2014-03-26 Thread Keiichi Fujino
The above code because it is used by the custom class of your own,
I am not able to reproduce this, but at least, as far as I see this code,
TcpPingInterceptor do not seem to use.

If using both TcpFailureDetector and StaticMembershipInterceptor,
TcpFailureDetector manages the membership of the static member.
However, in this case, the addition of the static members to membership can
be detected automatically by the heartbeat of TcpFailureDetector, but does
not detect the shutdown of the static member automatically.
(It is only possible to be detect members that fails to send message at
TcpFailureDetector.sendMessage.)

When using the StaticMembershipInterceptor(and TcpFailureDetector),
in order to detect the shutdown of the static member automatically by
heartbeat,
you must use the TcpPingInterceptor.
TcpPingInterceptor monitors cluster members by the TCP check.

ex.
TcpPingInterceptor -> TcpFailureDetector ->  StaticMembershipInterceptor



2014-03-25 2:11 GMT+09:00 D.R. :

> Hi,
>
> we are using tomcat 6.0.39 on linux machines.
> I've implemented a clustering via tribes for exchanging messages with
> static membership. We are not using mutlicast as it does not work with
> linux vserver. We are not using session replication. We just want to
> exchange some commands.
> Everything works fine, except that the cluster is not informed if a
> member from a different machine is shut down.
>
> For example:
> I have member1 and member2 on one machine with ip 192.168.0.88 and
> member3 and member4 on an other machine with ip 192.168.0.89
> If i shutdown member4, member3 calls the memberDisappeared() method of
> my membershiplistener.
> But this method is not called by the members member1 and member2.
> member1 and member2 are still referencing the dead member4, if i call
> channel.getmembers()
>
> This is my code for setting up the cluster:
>
> final StandardEngine engine = (StandardEngine)
> ServerFactory.getServer().findService(CATALINA_SERVICE).getContainer();
>
> final Container hostContainer = getHostContainer(engine);
>
> _simpleTcpCluster = new SimpleTcpCluster();
> _simpleTcpCluster.setProperty("channelStartOptions", 3);//disable
> multicast
> _simpleTcpCluster.setProperty("channelSendOptions", 8);// ???
>
> final TcpFailureDetector tcpFailureDetector = new TcpFailureDetector();
>
> final MyMessageDispatch15Interceptor messageDispatchInterceptor = new
> MyMessageDispatch15Interceptor();
> final MyChannelReceiver myChannelReceiver = new
> MyChannelReceiver(mysc.getClusterListenAddress());
> myChannelReceiver.setPort(_clusterPort);
>
> final StaticMembershipInterceptor staticMembershipInterceptor = new
> StaticMembershipInterceptor();
> final  Tuple2> members = getMembers();
> for(final Member member : members.getB()){
> if (member.isReady()) {
> LOGGER.info("[" + mysc.getStoreGroupId() + "-app] adding static
> member: " + MyMembershipListener.getMemberId(member));
> staticMembershipInterceptor.addStaticMember(member);
> } else {
> LOGGER.info("[" + mysc.getStoreGroupId() + "-app] static member
> not ready: " + MyMembershipListener.getMemberId(member) + ", not
> added");  //this is never called
> }
> }
> tcpFailureDetector.setNext(staticMembershipInterceptor);
> staticMembershipInterceptor.setPrevious(tcpFailureDetector);
> staticMembershipInterceptor.setNext(messageDispatchInterceptor);
> messageDispatchInterceptor.setPrevious(staticMembershipInterceptor);
> _myMembershipService = new MyMembershipService(members.getA());
> //
> myMembershipService.setMcastBindAddress(mysc.getClusterListenAddress());
> //forces an error
>
> _clusterChannel = new MyGroupChannel();
> _clusterChannel.setMembershipService(_myMembershipService);
> _clusterChannel.setChannelReceiver(myChannelReceiver);
> _clusterChannel.addInterceptor(tcpFailureDetector);
> _clusterChannel.addInterceptor(staticMembershipInterceptor);
> _clusterChannel.addInterceptor(messageDispatchInterceptor);
> _clusterChannel.addMembershipListener(_mbrListener);
> _clusterChannel.addChannelListener(_msgListener);
>
> _simpleTcpCluster.setChannel(_clusterChannel);
> hostContainer.setCluster(_simpleTcpCluster);
>
> try {
> _clusterChannel.start(Channel.DEFAULT);
> } catch (ChannelException e) {
> e.printStackTrace();
> }
>
> final Member[] group = _clusterChannel.getMembers();
> if(group.length < 1){
> LOGGER.info("[" + mysc.getStoreGroupId() + "-app] did not find any
> other cluster-members");
> } else {
> LOGGER.info("[" + mysc.getStoreGroupId() + "-app] found the
> following cluster-members:");
> for(final Member m : group){
> LOGGER.info("[" + mysc.getStoreGroupId() + "-app] name: " +
> m.getName() + ", port: " + m.getPort() + ", uniqueid: " +
> MyMembershipListener.getMemberId(m));
> }
> }
>
> Any help is welcome.
>
>
> With kind regards
> Dave
>
> --
> Keiichi.Fujino


Re: Apache Tomcat Summit at ApacheCon NA 2014

2014-01-27 Thread Keiichi Fujino
2014-01-23 Mark Thomas 

> ApacheCon NA will be in Denver 7th to 11th April.
>
> The schedule for ApacheCon NA 2014 has been firmed up. There is an
> opportunity for a project summit on either the Thursday or the Friday.
> Since the BarCamp has been scheduled for the Thursday the Friday seems
> like the better option.
>
> We have complete flexibility as to the organisation of the Summit. One
> possible topic is with the Java EE 7 work pretty much complete, what new
> features is the community interested in between now and when the Java EE
> 8 work starts? Other suggestions for topics welcome.
>
> To get this up and running we need an idea of how many folks might want
> to attend so please reply to this thread on the users list if:
> - you are interested in attending
> - you have a topic / some topics to suggest
>
> Thanks,
>
> Mark
>
>
I'm going to participate in ApacheCon. And I'm interested in these events.
If these events are to be held, I'm going to join with pleasure.

-- 
Keiichi.Fujino


Re: Tomcat Clustering - when the tomcat instances are on different machines

2013-12-17 Thread Keiichi Fujino
In order to trace create session completely, it was necessary that changing
log level of LazyReplicatedMap. (sorry about that.)

However this log indicates that session replication works.

For example.

Dec 17, 2013 1:52:21 PM
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap messageReceived
> FINER: Map message received from:tcp://{127, 0, 1, 1}:5000
> msg:MapMessage[context=/HATest-map; type=MSG_BACKUP;
> key=69713914F61869565FF52E909EDB7C1C;
> value=DeltaSession[69713914F61869565FF52E909EDB7C1C]
>

This log means that  tc1 received session replication
message(type=MSG_BACKUP) from tc2.
session Id is 69713914F61869565FF52E909EDB7C1C.


> Dec 17, 2013 1:52:21 PM
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap replicate
> FINER: Replicate invoked on key:69713914F61869565FF52E909EDB7C1C
>
>
This log means that tc1 replicate session attribute to tc2.
sesison Id is 69713914F61869565FF52E909EDB7C1C.



-- 
Keiichi.Fujino


Re: Tomcat Clustering - when the tomcat instances are on different machines

2013-12-17 Thread Keiichi Fujino
2013/12/17 Nir A 

> In the tomcat manager We can see that our web application called "HATest"
> is having the sessions.
> Its a small demo of a shopping cart that keeps the items in the session.
>
> here is an example of a session we created in on of the tomcats nodes:
>
> Details for Session 33265A9C6318C014ADA92220A76F566C  Session Id
> 33265A9C6318C014ADA92220A76F566C  Guessed Locale
>  Guessed User
>  Creation Time 2013-12-17 11:56:07  Last Accessed Time 2013-12-17
> 12:01:13  Session
> Max Inactive Interval 00:30:00  Used Time 00:05:06  Inactive Time 00:00:02
> TTL 00:29:57
>   1 attributes  Remove Attribute Attribute name Attribute value
>
> Books [my book!, Some other book]
>
>
>
Does this say that there is only one session?
You said "We have 3 sessions currently: one on node-1 and 2 on node-2" on
previous mail.
In other words, do you say that manager app should display 3 sessions (both
primary and backup) ?


>
> In our previous POC where all instances were local we had this exact
> session replication.
> We could see on the manager of instance 2 that a new "Backup" session is
> created (replicated) right after the creation of a new session in instance
> 1..
>
> 1) is it possible to get some more logging info from anywhere?
> 2) How come when i create a new session in an instance we dont see in the
> catalina.log another message being fired to update?
>
>
If you change log level of AbstractReplicatedMap, you can trace the session
replication of BackupManager.

e.g. logging.propertie
java.util.logging.ConsoleHandler.level = FINEST
org.apache.catalina.tribes.tipis.AbstractReplicatedMap.level = FINEST





> Thanks again,
>
>
>
> On Tue, Dec 17, 2013 at 11:54 AM, Keiichi Fujino 
> wrote:
>
> > It seems that there is no problem.
> > Initialization of AbstractReplicatedMap seems to work correctly.
> >
> >
> >
> > >
> > > We have 3 sessions currently: one on node-1 and 2 on node-2 but there
> are
> > > only primary sessions on each (3) and not backup sessions at all. what
> > > could be the problem?
> > >
> > >
> > How did you confirm this?
> > please show more detail.
> >
> >
> >
> > > On Tue, Dec 17, 2013 at 10:25 AM, Keiichi Fujino 
> > > wrote:
> > >
> > > > DeltaManager starts session sync phase by sending a SESSION-GET-ALL
> > > message
> > > > at startup.
> > > > DeltaManager that has received the SESSION-GET-ALL message sends all
> > > > session data by sending a ALL-SESSION-DATA message.
> > > > Then sends a SESSION-STATE-TRANSFERED message in order to notify the
> > > > transmission completion.
> > > > DeltaManager that has received the SESSION-STATE-TRANSFERED message
> > > > completes session sync phase.
> > > >
> > > >
> > > > According to this log,
> > > >
> > > >
> > > >
> > > > > Dec 16, 2013 6:43:29 PM org.apache.catalina.ha.session.DeltaManager
> > > > > waitForSendAllSessions
> > > > > SEVERE: Manager [/HATest]: No session state send at 12/16/13 6:42
> PM
> > > > > received, timing out after 60,102 ms.
> > > > >
> > > >
> > > > This log means that time-out occurred in session sync phase. (Default
> > 60
> > > > seconds)
> > > >
> > > > and
> > > >
> > > >
> > > >
> > > > > Dec 16, 2013 6:43:29 PM org.apache.catalina.ha.session.DeltaManager
> > > > > getAllClusterSessions
> > > > > WARNING: Manager [/HATest]: Drop message SESSION-GET-ALL inside
> > > > > GET_ALL_SESSIONS sync phase start date 12/16/13 6:42 PM message
> date
> > > > 1/1/70
> > > > > 2:00 AM
> > > > >
> > > >
> > > > This log means that SESSION-GET-ALL message that received during
> > session
> > > > sync phase is dropped.
> > > >
> > > > Thus, It seems that two nodes were started at the same time.
> > > > If SESSION-GET-ALL message is dropped, SESSION-STATE-TRANSFERED
> message
> > > can
> > > > not be received.
> > > > As a result, will be time-out  in session sync phase.
> > > >
> > > > You should start Tomcat in proper order (rather than simultaneously).
> > > >
> > > > Another problem.
> > > > In warning log, time stamp of the SESSION-GET-ALL messages that were
> > > > dropped has become to 1/1/70

Re: Tomcat Clustering - when the tomcat instances are on different machines

2013-12-17 Thread Keiichi Fujino
It seems that there is no problem.
Initialization of AbstractReplicatedMap seems to work correctly.



>
> We have 3 sessions currently: one on node-1 and 2 on node-2 but there are
> only primary sessions on each (3) and not backup sessions at all. what
> could be the problem?
>
>
How did you confirm this?
please show more detail.



> On Tue, Dec 17, 2013 at 10:25 AM, Keiichi Fujino 
> wrote:
>
> > DeltaManager starts session sync phase by sending a SESSION-GET-ALL
> message
> > at startup.
> > DeltaManager that has received the SESSION-GET-ALL message sends all
> > session data by sending a ALL-SESSION-DATA message.
> > Then sends a SESSION-STATE-TRANSFERED message in order to notify the
> > transmission completion.
> > DeltaManager that has received the SESSION-STATE-TRANSFERED message
> > completes session sync phase.
> >
> >
> > According to this log,
> >
> >
> >
> > > Dec 16, 2013 6:43:29 PM org.apache.catalina.ha.session.DeltaManager
> > > waitForSendAllSessions
> > > SEVERE: Manager [/HATest]: No session state send at 12/16/13 6:42 PM
> > > received, timing out after 60,102 ms.
> > >
> >
> > This log means that time-out occurred in session sync phase. (Default 60
> > seconds)
> >
> > and
> >
> >
> >
> > > Dec 16, 2013 6:43:29 PM org.apache.catalina.ha.session.DeltaManager
> > > getAllClusterSessions
> > > WARNING: Manager [/HATest]: Drop message SESSION-GET-ALL inside
> > > GET_ALL_SESSIONS sync phase start date 12/16/13 6:42 PM message date
> > 1/1/70
> > > 2:00 AM
> > >
> >
> > This log means that SESSION-GET-ALL message that received during session
> > sync phase is dropped.
> >
> > Thus, It seems that two nodes were started at the same time.
> > If SESSION-GET-ALL message is dropped, SESSION-STATE-TRANSFERED message
> can
> > not be received.
> > As a result, will be time-out  in session sync phase.
> >
> > You should start Tomcat in proper order (rather than simultaneously).
> >
> > Another problem.
> > In warning log, time stamp of the SESSION-GET-ALL messages that were
> > dropped has become to 1/1/70.
> > This is just a trivial bug.
> > I will fix this later.
> > That way, the correct time stamp will be output.
> >
> >
> >
> >
> > > Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> > > deployDirectory
> > > INFO: Deploying web application directory
> > > /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/docs
> > > Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> > > deployDirectory
> > > INFO: Deploying web application directory
> > > /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/host-manager
> > > Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> > > deployDirectory
> > > INFO: Deploying web application directory
> > > /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/ROOT
> > > Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> > > deployDirectory
> > > INFO: Deploying web application directory
> > > /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/examples
> > > Dec 16, 2013 6:43:30 PM org.apache.catalina.startup.HostConfig
> > > deployDirectory
> > > INFO: Deploying web application directory
> > > /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/manager
> > > Dec 16, 2013 6:43:30 PM org.apache.catalina.ha.session.DeltaManager
> > > startInternal
> > > INFO: Register manager /manager to cluster element Host with name
> > localhost
> > > Dec 16, 2013 6:43:30 PM org.apache.catalina.ha.session.DeltaManager
> > > startInternal
> > > INFO: Starting clustering manager at /manager
> > > Dec 16, 2013 6:43:30 PM org.apache.catalina.ha.session.DeltaManager
> > > getAllClusterSessions
> > > INFO: Manager [/manager], requesting session state from
> > > org.apache.catalina.tribes.membership.MemberImpl[tcp://{127, 0, 1,
> > > 1}:5000,{127, 0, 1, 1},5000, alive=65057, securePort=-1, UDP Port=-1,
> > > id={-90 41 -113 110 96 -50 78 -88 -79 -103 1 61 -60 -125 75 44 },
> > > payload={}, command={}, domain={}, ]. This operation will timeout if no
> > > session state has been received within 60 seconds.
> > > Dec 16, 2013 6:44:16 PM
> > > org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
> > > memberDisappeared
> > > INFO: Verification complete. Member
> > >
> disappeared[org.apache.catal

Re: Tomcat Clustering - when the tomcat instances are on different machines

2013-12-17 Thread Keiichi Fujino
DeltaManager starts session sync phase by sending a SESSION-GET-ALL message
at startup.
DeltaManager that has received the SESSION-GET-ALL message sends all
session data by sending a ALL-SESSION-DATA message.
Then sends a SESSION-STATE-TRANSFERED message in order to notify the
transmission completion.
DeltaManager that has received the SESSION-STATE-TRANSFERED message
completes session sync phase.


According to this log,



> Dec 16, 2013 6:43:29 PM org.apache.catalina.ha.session.DeltaManager
> waitForSendAllSessions
> SEVERE: Manager [/HATest]: No session state send at 12/16/13 6:42 PM
> received, timing out after 60,102 ms.
>

This log means that time-out occurred in session sync phase. (Default 60
seconds)

and



> Dec 16, 2013 6:43:29 PM org.apache.catalina.ha.session.DeltaManager
> getAllClusterSessions
> WARNING: Manager [/HATest]: Drop message SESSION-GET-ALL inside
> GET_ALL_SESSIONS sync phase start date 12/16/13 6:42 PM message date 1/1/70
> 2:00 AM
>

This log means that SESSION-GET-ALL message that received during session
sync phase is dropped.

Thus, It seems that two nodes were started at the same time.
If SESSION-GET-ALL message is dropped, SESSION-STATE-TRANSFERED message can
not be received.
As a result, will be time-out  in session sync phase.

You should start Tomcat in proper order (rather than simultaneously).

Another problem.
In warning log, time stamp of the SESSION-GET-ALL messages that were
dropped has become to 1/1/70.
This is just a trivial bug.
I will fix this later.
That way, the correct time stamp will be output.




> Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/docs
> Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/host-manager
> Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/ROOT
> Dec 16, 2013 6:43:29 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/examples
> Dec 16, 2013 6:43:30 PM org.apache.catalina.startup.HostConfig
> deployDirectory
> INFO: Deploying web application directory
> /usr/local/tomcat7/apache-tomcat-7.0.47/webapps/manager
> Dec 16, 2013 6:43:30 PM org.apache.catalina.ha.session.DeltaManager
> startInternal
> INFO: Register manager /manager to cluster element Host with name localhost
> Dec 16, 2013 6:43:30 PM org.apache.catalina.ha.session.DeltaManager
> startInternal
> INFO: Starting clustering manager at /manager
> Dec 16, 2013 6:43:30 PM org.apache.catalina.ha.session.DeltaManager
> getAllClusterSessions
> INFO: Manager [/manager], requesting session state from
> org.apache.catalina.tribes.membership.MemberImpl[tcp://{127, 0, 1,
> 1}:5000,{127, 0, 1, 1},5000, alive=65057, securePort=-1, UDP Port=-1,
> id={-90 41 -113 110 96 -50 78 -88 -79 -103 1 61 -60 -125 75 44 },
> payload={}, command={}, domain={}, ]. This operation will timeout if no
> session state has been received within 60 seconds.
> Dec 16, 2013 6:44:16 PM
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
> memberDisappeared
> INFO: Verification complete. Member
> disappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{127, 0,
> 1, 1}:5000,{127, 0, 1, 1},5000, alive=112037, securePort=-1, UDP Port=-1,
> id={-90 41 -113 110 96 -50 78 -88 -79 -103 1 61 -60 -125 75 44 },
> payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]]
> Dec 16, 2013 6:44:16 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> memberDisappeared
> INFO: Received member
> disappeared:org.apache.catalina.tribes.membership.MemberImpl[tcp://{127, 0,
> 1, 1}:5000,{127, 0, 1, 1},5000, alive=112037, securePort=-1, UDP Port=-1,
> id={-90 41 -113 110 96 -50 78 -88 -79 -103 1 61 -60 -125 75 44 },
> payload={}, command={66 65 66 89 45 65 76 69 88 ...(9)}, domain={}, ]
> Dec 16, 2013 6:44:22 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> memberAdded
> INFO: Replication member
> added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{127, 0, 1,
> 1}:5000,{127, 0, 1, 1},5000, alive=1014, securePort=-1, UDP Port=-1, id={75
> 3 86 -1 25 78 67 111 -125 -65 74 58 79 -20 93 16 }, payload={}, command={},
> domain={}, ]
> Dec 16, 2013 6:44:30 PM org.apache.catalina.ha.session.DeltaManager
> waitForSendAllSessions
> SEVERE: Manager [/manager]: No session state send at 12/16/13 6:43 PM
> received, timing out after 60,081 ms.
> Dec 16, 2013 6:44:30 PM org.apache.catalina.ha.session.DeltaManager
> getAllClusterSessions
> WARNING: Manager [/manager]: Drop message SESSION-GET-ALL inside
> GET_ALL_SESSIONS sync phase start date 12/16/13 6:43 PM message date 1/1/70
> 2:00 AM
> Dec 16, 2013 6:44:30 PM org.apache.coyote.A

Re: BackupManager start fails under heavy load

2013-07-02 Thread Keiichi Fujino
2013/6/28 Patrick Savage 

> We have an issue in our Tomcat 7.0.30 clustered production environment on
> RHEL 5 where Tomcat fails to start our application when other nodes in the
> cluster are under extremely heavy load. It fails because the BackupManager
> cannot start the replicated map due to timeouts trying to connect to all
> the
> other nodes. The only way to recover from this seems to be shutting down
> almost all of the nodes and then starting them again. The cluster has 9
> nodes, but we have also had the problem with 6 nodes.
>
>
>
> Is there a way to ensure the application will start even if the
> BackupManager cannot connect to the other nodes?


No.
If replication map fails to start, associated context will fail to start.

I will implement a feature  to ensure the application will start even If
replication map fails to start.

-- 
Keiichi.Fujino


Re: Static Membership Session Replication

2012-09-24 Thread Keiichi Fujino
Hi

According to this log,
it does not seem to able to register for membership.
In your configuration, TcpFailureDetector behaves as an administrator
of a membership.
Therefore, TcpFailureDetector#performBasicCheck logs following messages.
[WARNING: Member added, even though we werent notified:*member*]
or
[INFO: Suspect member, confirmed alive.]

However,  these message does not exist in log.
It maybe remains in TcpFailureDetector#addSuspects.

Regarding your configuration.

*tomcatone server.xml*
 

Is it not address="localhost" but address="tomcatone" ?

*tomcat2 server.xml*
 

Is it not address="localhost" but address="tomcattwo" ?

2012/9/21 John Rellis :
> Hey,
>
> Really hoping somebody can help.  I am attempting a cluster with session
> replication.  Tomcat 7, apache with mod_jk.  The cluster and load balancing
> seems to be ok but I cannot get session replication working.  I am using
> static membership as I am testing this on EC2.  The load balancer and 2
> workers are on individual servers.
>
> I have two tomcat instances, tomcatone and tomcattwo.  When starting up
> tomcattwo I saw this ONCE on tomcattwo and never again :
>
> *INFO: Manager [localhost#/ClusterApp], requesting session state from
> org.apache.catalina.tribes.membership.MemberImpl[tcp://tomcatone:4110,tomcatone,4110,
> alive=0, securePort=-1, UDP Port=-1, id={1 2 3 4 5 6 7 8 9 10 11 12 13 14
> 15 1 }, payload={}, command={}, domain={100 101 108 116 97 45 115 116 97
> ...(12)}, ]. This operation will timeout if no session state has been
> received within 60 seconds.*
> *Sep 20, 2012 3:19:45 PM org.apache.catalina.ha.session.DeltaManager
> waitForSendAllSessions*
> *SEVERE: Manager [localhost#/ClusterApp]: No session state send at 9/20/12
> 3:18 PM received, timing out after 60,109 ms.*
>
> The failure was due to firewall I think.  Now the firewall is open and I
> haven't seen this again.  Weird.  Right now it doesn't look like the nodes
> are trying to communicate at all.
>
> Many thanks in advance!
>
> Server.xml's and logs :
>
> *tomcatone server.xml*
> *
> *
> 
> 
> 
> 
>   
>   
>SSLEngine="on" />
>   
>   
>   
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>
>   
>   
> 
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>   
>
>   
>   
>
> 
> 
>
>
> 
> connectionTimeout="2"
>redirectPort="8443" />
> 
> 
> 
> 
>
> 
> 
>
>
> 
>
> 
> 
>
>   
>
>channelSendOptions="8" channelStartOptions="3">
>
> 
>   expireSessionsOnShutdown="false"
>
>   notifyListenersOnReplication="true"/>
>
>
> 
>
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>
> address="localhost" port="4110" autoBind="100"
>
> selectorTimeout="5000" maxThreads="6"/>
>
>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>  className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> 
>
>
>  className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"/>
>  className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>  className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>
>  className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
> 
>  className="org.apache.catalina.tribes.membership.StaticMember"
>
>
> port="4210"
> host="tomcattwo"
> domain="delta-static"
>
> uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,2}"
> />
> 
>
> 
>
>  filter=""/>
>
>  className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>  className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
>
>  className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>
>   
>
>
>   
>   
> 
> resourceName="UserDatabase"/>
>   
>
>unpackWARs="true" autoDeploy="true">
>
> 
> 
>
> 
>  directory="logs"
>prefix="localhost_access_log." suffix=".txt"
>pattern="%h %l %u %t "%r" %s %b" />
>
>   
> 
>   
> 
>
>
> *tomcat2 server.xml*
> 
> 
> 
> 
>   
>  

Re: Tomcat 7 Manager App Authentication failure

2012-06-29 Thread Keiichi Fujino
Hi

Is "etc/tomcat5/tomcat-users.xml" correct?
The absolute path needs to start with "/".
The correct pathname is "/etc/tomcat5/tomcat-users.xml".


2012/6/29 kl2eativ :
> Hello. I am having problems trying to authenticate my tomcat 7 manager app. I
> keep getting a 401 Unauthorized page. My config is as follows:
> tomcat-users.xml (Located in /etc/tomcat5)
> [code]
>   
>  
>  
>  
>  
> [/code]
>
> server.xml (Located in /etc/tomcat5)
> [code]
>
>                            type="org.apache.catalina.UserDatabase"
>              description="User database that can be updated and saved"
>              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>              pathname="etc/tomcat5/tomcat-users.xml" />
> [/code]
>
> I restart the tomcat service ( #service tomcat restart ) , but still cannot
> authenticate. Your help would be greatly
> appreciated.
>
> --
> View this message in context: 
> http://tomcat.10.n6.nabble.com/Tomcat-7-Manager-App-Authentication-failure-tp4983418.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>



-- 
Keiichi.Fujino

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: FarmWarDeployer undeploy on slave node when tomcat restart

2011-10-21 Thread Keiichi Fujino
I checked FarmWarDeployer's code.
When WAR is updated, FarmWarDeployer sends UndeployMessage and sends
FileMessage after that.
The node which received UndeployMessage undeploys war.
The node which received FileMessage deploys war.

If FileMessage is received while processing UndeployMessage, the
following error messages will be outputted.
"SEVERE: Application /example in used. touch war file example.war again!"

In the case of asynchronous replication (default), FileMessage may be
received while processing UndeployMessage.

I think that it may be better to process updated war by one message.
Although I consider correction of a code, there is one work around.

Workaround is change in synchronous mode.

Please try the following.



2011/10/21 Marco Betti :
> Tried also on Tomcat 7.0.22
>
> Same behaviour: when i restart node1, FarmWarDeployer undeploy my war both
> from node1 and node2, but re-deploy it only on node1.
> If I touch my war in my watchDir on node1, tomcat redeploys it correctly on
> both nodes...
>
> Is tomcat clustering used?
>
> If so, does anybody use FarmWarDeployer  ?
>
> Many thanks,
> Marco
>
>
>
> On Thu, Oct 20, 2011 at 6:21 PM, Marco Betti  wrote:
>
>> Hi all,
>> I'm new to the list.
>> I'm trying to configure tomcat 6.0.33 clustering.
>> Session replication is ok.
>> I've a problem with FarmWarDeployer.
>> I found that:
>>
>> 1. You have to place the  node under the  element.
>>
>> Tomcat 6.0.x complains that the element Cluster/Deployer element is not
>> understood at the Engine level.
>>
>> 2. One node needs to have watchEnabled="true", all other nodes
>> watchEnabled="false"
>>
>> 3. deployDir is the same as appBase
>>
>>
>> and after I found this post that confirmed these points to me:
>>
>> http://www.mail-archive.com/users@tomcat.apache.org/msg80374.html
>>
>> The problem is the following:
>> let node1 be the master (watchEnabled="true") and node2 the slave
>> (watchEnabled="false")
>> This is my configuration:
>> >
>> tempDir="/appserv/tomcat/tomcat60/apache-tomcat-6.0.33/server/clu001node01/temp/"
>>
>> deployDir="/appserv/tomcat/tomcat60/apache-tomcat-6.0.33/server/clu001node01/webapps/"
>>
>> watchDir="/appserv/tomcat/tomcat60/apache-tomcat-6.0.33/server/clu001node01/farm/"
>>                     watchEnabled="true"/>
>>
>>
>> If I copy a war to watchDir of node1 evertything works fine and cluster
>> deploy is achieved.
>>
>> When i restart node1, FarmWarDeployer undeploy my war both from node1 and
>> node2, but re-deploy it only on node1.
>>
>> node1 log:
>>
>> INFO: Cluster wide remove of web app /example
>> Oct 20, 2011 5:50:46 PM org.apache.catalina.startup.HostConfig
>> checkResources
>> INFO: Undeploying context [/example]
>> Oct 20, 2011 5:50:46 PM org.apache.catalina.startup.HostConfig deployWAR
>> INFO: Deploying web application archive example.war
>>
>>
>> node2 log:
>>
>> INFO: Undeploying context [/example]
>> Oct 20, 2011 5:50:47 PM org.apache.catalina.ha.deploy.FarmWarDeployer
>> messageReceived
>> SEVERE: Application /example in used. touch war file example.war again!
>>
>>
>> Obviously, if I touch my war in my watchDir on node1, tomcat redeploys it
>> correctly on both nodes... but this cannot be the solution...
>>
>>
>> Is it a known problem?
>>
>> Could anyone help me?
>>
>> Many thanks,
>> Marco
>>
>



-- 
Keiichi.Fujino

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [ANN] New Tomcat committer: Sylvain Laurent (slaurent)

2010-12-02 Thread Keiichi Fujino
2010/12/3 Mark Thomas :
> On behalf of the Tomcat committers I am pleased to announce that Sylvain
> Laurent (slaurent) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>

Welcome Sylvain!

-- 
Keiichi.Fujino

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [ANN] New Tomcat committer: Christopher Schultz (schultz)

2010-11-23 Thread Keiichi Fujino
2010/11/23 Mark Thomas :
> On behalf of the Tomcat committers I am pleased to announce that
> Christopher Schultz (schultz) has been voted in as a new Tomcat committer.
>
> Please join me in welcoming him.
>

Congratulations!

-- 
Keiichi.Fujino

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Redeploy problem in 6.0.20

2009-10-18 Thread Keiichi Fujino

I don't know target date for the release of 6.0.21.


Andrew Morgan wrote:
> 
> On Thu, 15 Oct 2009, Keiichi Fujino wrote:
> 
>>
>> Hi Andrew.
>>
>> Check this BZ47343.
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=47343
>>
>> Perhaps, it is the same as this BugReport.
>> This bug is corrected by 6.0.21.
>>
>> Best Regards.
> 
> That does sound like my problem!  Is there a target date for the release 
> of 6.0.21?
> 
> Thanks,
>   Andy
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Redeploy-problem-in-6.0.20-tp25915514p25952261.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Redeploy problem in 6.0.20

2009-10-15 Thread Keiichi Fujino

Hi Andrew.

Check this BZ47343.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47343

Perhaps, it is the same as this BugReport.
This bug is corrected by 6.0.21.

Best Regards.


-- 
View this message in context: 
http://www.nabble.com/Redeploy-problem-in-6.0.20-tp25915514p25919112.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org