Weblogic doesn't cache LDAP - ldap

I have a web application set up using JSF 2.1 and JEE 6 running on a WebLogic 12.1.2 server with an openLDAP for authentication. I've been noticing that loading any page in the app causes multiple BIND requests to LDAP – every single time!
I've read through much of the material and have configured the LDAP provider in Weblogic such that just about any cache I could find is activated. In particular I've set
[x] Cache Enabled
Cache Size: 10240
Cache TTL: 300
GUID Attribute: entryUUID
I've also double-checked that the entryUUID attribute exists. I'm not too knowledgable on either WebLogic or LDAP, but I've read just about any page on configuring the cache, but there's still just as many requests to the LDAP (yes, I've restarted the servers after changes.)
I'd appreciate any help, insights or wild guesses as to what may be the cause or how I can debug this issue further. I'm not too sure which config files to attach, but if there's anything needed I'm happy to provide it.
The LDAP requests all look like this:
# journalctl -u slapd
# … many of these …
Sep 16 23:06:03 server.org slapd[15038]: daemon: read active on 13
Sep 16 23:06:03 server.org slapd[15038]: daemon: epoll: listen=7 active_threads=0 tvp=zero
Sep 16 23:06:03 server.org slapd[15038]: daemon: epoll: listen=8 active_threads=0 tvp=zero
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND anonymous mech=implicit ssf=0
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND dn="tpid=NQ00000013,ou=people,dc=de,dc=foobiz,dc=com" method=128
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 BIND dn="tpid=NQ00000013,ou=people,dc=de,dc=foobiz,dc=com" mech=SIMPLE ssf=0
Sep 16 23:06:03 server.org slapd[15038]: conn=1109 op=32 RESULT tag=97 err=0 text=
Sep 16 23:06:03 server.org slapd[15038]: daemon: activity on 1 descriptor
Sep 16 23:06:03 server.org slapd[15038]: daemon: activity on:

I have figured out the issue and WebLogic isn't at fault whatsoever. Our application seems to be using a rather broken concept of calling remote EJBs where it creates its own proxy, stores the JNDI information and executes a JNDI lookup on every method invocation.
Therefore, even caching the bean wouldn't help. Of course this bypasses any caching mechanisms and thus results in multiple LDAP binds with every request.

Related

Nginx and Solr server on port 8983 but can't access Admin area

Im running Nginx and I just installed solr.
Service status reports everythign is ok...
sudo service solr statusroot#closer:~# sudo service solr status
● solr.service - LSB: Controls Apache Solr as a Service
Loaded: loaded (/etc/init.d/solr; bad; vendor preset: enabled)
Active: active (exited) since Sat 2018-07-14 18:21:14 UTC; 1s ago
Docs: man:systemd-sysv-generator(8)
Process: 2549 ExecStop=/etc/init.d/solr stop (code=exited, status=0/SUCCESS)
Process: 2699 ExecStart=/etc/init.d/solr start (code=exited, status=0/SUCCESS)
Jul 14 18:21:08 closer solr[2699]: If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false in your profile or solr.in.sh
Jul 14 18:21:08 closer solr[2699]: *** [WARN] *** Your Max Processes Limit is currently 3896.
Jul 14 18:21:08 closer solr[2699]: It should be set to 65000 to avoid operational disruption.
Jul 14 18:21:08 closer solr[2699]: If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false in your profile or solr.in.sh
Jul 14 18:21:08 closer solr[2699]: Warning: Available entropy is low. As a result, use of the UUIDField, SSL, or any other features that require
Jul 14 18:21:08 closer solr[2699]: RNG might not work properly. To check for the amount of available entropy, use 'cat /proc/sys/kernel/random/entr
Jul 14 18:21:14 closer solr[2699]: [194B blob data]
Jul 14 18:21:14 closer solr[2699]: Started Solr server on port 8983 (pid=2751). Happy searching!
Jul 14 18:21:14 closer solr[2699]: [14B blob data]
Jul 14 18:21:14 closer systemd[1]: Started LSB: Controls Apache Solr as a Service.
but if I try to go to xxx.xxx.xxx.xxx:8983/solr
I can't access the page...why?
do i have to ufw port 8983?
do i have to start apache?
else?
It worked after
sudo ufw allow 8983
I can't believe all the online guides never mentioned it.

Jboss Mod_cluster

I have a jboss cluster with 2 nodes (a and b) + 1 apache working as mod_cluster (apache in a separate server)
If one of the nodeA goes down, mod cluster can't connect to another one.
So, if nodeA crashes, I can't access jboss aplication by http://apache_server/myapp, but I can by http://nodeb/myapp and vice-versa
I dig on google almost all i have found say that is related to sessions but I can't fnd whats is wron with my config. (Mod_cluster as configured with this tool Load Balancer Configuration Tool
NodeA Log
15/05/2016 07:45:22,741 ERROR [org.jgroups.protocols.TCP] (http-/nodeA:8080-90) failed sending message to jbossnodeb:jbossnodeb/web (4148 bytes): java.net.SocketException: Socket closed, cause: null
15/05/2016 07:45:22,790 ERROR [org.jgroups.protocols.TCP] (OOB-6464,shared=tcp) failed sending message to jbossnodeb:jbossnodeb/web (4141 bytes): java.net.SocketException: Broken pipe, cause: null
NodeB Log
15/05/2016 07:45:23,126 ERROR [org.jgroups.protocols.TCP] (OOB-4949,shared=tcp) failed sending message to jbossnodea:jbossnodea/web (79 bytes): java.net.SocketException: Broken pipe, cause: null
15/05/2016 07:45:53,457 WARN [org.jgroups.protocols.TCP] (Timer-1,shared=tcp) null: no physical address for jbossnodea:jbossnodea/web, dropping message
Apache mod_cluster server log
[Sun May 15 07:45:04 2016] [error] (70007)The timeout specified has expired: proxy: read response failed from (null) (nodeA_IP)
[Sun May 15 07:45:34 2016] [error] (70007)The timeout specified has expired: ajp_cping_cpong: apr_socket_recv failed
[Sun May 15 07:45:38 2016] [error] ajp_handle_cping_cpong: ajp_ilink_receive failed
[Sun May 15 07:45:38 2016] [error] (70007)The timeout specified has expired: proxy: AJP: cping/cpong failed to (null) (nodeA_IP)
[Sun May 15 07:45:44 2016] [error] (70007)The timeout specified has expired: ajp_cping_cpong: apr_socket_recv failed
[Sun May 15 07:45:44 2016] [error] (70007)The timeout specified has expired: proxy: dialog to nodeA_IP:8009 (nodeA_IP) failed
[Sun May 15 07:45:44 2016] [error] ajp_read_header: ajp_ilink_receive failed
[Sun May 15 07:45:44 2016] [error] (70007)The timeout specified has expired: proxy: dialog to nodeA_IP:8009 (nodeA_IP) failed
[Sun May 15 07:45:44 2016] [error] (70007)The timeout specified has expired: proxy: dialog to nodeA_IP:8009 (nodeA_IP) failed
[Sun May 15 07:45:45 2016] [error] ajp_read_header: ajp_ilink_receive failed
[Sun May 15 07:45:45 2016] [error] (70007)The timeout specified has expired: proxy: dialog to (null) (nodeA_IP) failed
[Sun May 15 07:45:45 2016] [error] ajp_read_header: ajp_ilink_receive failed
[Sun May 15 07:45:45 2016] [error] (70007)The timeout specified has expired: proxy: dialog to (null) (nodeA_IP) failed
[Sun May 15 07:45:45 2016] [error] ajp_read_header: ajp_ilink_receive failed
[Sun May 15 07:45:45 2016] [error] proxy: CLUSTER: (balancer://clusterjboss). All workers are in error state
Config apache mod_cluster
AdvertiseGroup 225.0.1.107:23364
KeepAliveTimeout 60
ManagerBalancerName clusterjboss
ServerAdvertise On
AdvertiseFrequency 5
EnableMCPMReceive
CreateBalancers 0
AllowDisplay On
ProxyPass / balancer://clusterjboss/ stickysession=JSESSIONID|jsessionid nofailover=On
Visibility
JBoss worker instances must be able to contact your ```EnableMCPMReceive`` VirtualHost
Your JBoss worker instances report their IP address and AJP port to the Apache HTTP Server
Your Apache HTTP Server must be able to contact them back on those reported addresses
ProxyPass
JGroups, Infinispan, Domains, Clustering
mod_cluster, i.e. modcluster subsystem has nothing to do with the aforementioned whatsoever. The subsystem is completely oblivious to the fact that there is some cluster formed or that you have your instances in a domain -- which is also irrelevant to having your instances in a cluster in the first place. Don't bother with JGroups messages while investigating mod_cluster configuration.
Although, if your JGroups cluster is broken...
Infinispan - i.e. distributed or replicated cache of your web session data in this case, relies on JGroups for forming a cluster and for exchanging messages in this cluster. If your instances cannot for a cluster or fail to exchange messages, you might experience a loss of session data on failover.
For example: Apache HTTP Server mod_cluster balacner decides to send request with JSESSIONID yadayadaXXX.worker-1 to worker-2, because worker-1 is down. Due to a network configuration error, worker-1 and worker-2 has never correctly formed a cluster, so worker-2 does not have the session data of worker-1. The result is a web application with a new session created, i.e. your client lost his context, e.g. shopping cart (popular showcase).
ProxyPass
Don't use it unless you have something specific in mind. The whole point of mod_cluster is that it creates all proxy directives in memory, on the fly dynamically as your worker nodes and their web applications come and go. You start fiddling with additional ProxyPass directives if you want to:
react to special error codes from a special web applciation, e.g. to treat HTTP codes that are supposed to mean an error as valid and vice versa
to serve static content directly from the Apache HTTP Server and not from worker nodes - e.g. pictures...
to load balance some contexts to mod_cluster-aware JBoss worker nodes and some contexts to non-mod_cluster servers, e.g. another Apache HTTP Server running Drupal in PHP...
ManagerBalancerName
It is not clear to me why you would need to change it. If you change the default value, you have to also alter balancer="new_value" in your Jboss modcluster subsystem configuration. What is actually does is that it tells mod_cluster in the Apache HTTP Server to create more separate named ProxyPass Balacners internally. One then could use ProxyPass directives to tweak them separately. Do you need to tweak them? According to the rest of your config I am convinced it is not the case. For example, the session stickiness is configured in JBoss nodes in mod_cluster subsystems - worker ndoes report this to the Apache HTTP Server balancer.
HTH, -K-
Possible changes that need to be done in domain.xml:
1. Under < domain-controller>, add < remote host="< ip-address-of-master-node>" port="< port>" security-realm="ManagementRealm"/>
2. Under < servers>, add < server name="slave-node" group="server-group" auto-start="true">
3. Under mod-cluster subsystem, add < mod-cluster-config advertise-socket="modcluster" proxy-list="< ip-address>:< port-in-mod-cluster-config" connector="ajp">
In mod-cluster configuration:
1. Allow from all
2. ManagerBalancerName server-group (exact name as above)
Also, are you using any virtualization/containers? To deal problems with session replication in such cases, you might need to try out "sticky session".

Apache Tomcat and Mod_jk

We have been running Apache with Tomcat using mod_jk for about a month now with out issues. This morning I have started seeing the error below in the mod_jk log files.
I am fairly new to using mod_jk and am not sure how to increase the number of connections, see the number of active connections and/or kill of connections that are idle or dead.
Any ideas/help would be much appreciated.
[Thu Sep 19 11:02:42 2013] [1644:11984] [warn] ajp_get_endpoint::jk_ajp_common.c (3177): Unable to get the free endpoint for worker Worker1 from 10 slots
[Thu Sep 19 11:02:42 2013] [1644:11984] [error] jk_handler::mod_jk.c (2726): Could not get endpoint for worker=Worker1
[Thu Sep 19 11:02:42 2013] [1644:11984] [info] jk_handler::mod_jk.c (2788): Service error=0 for worker=Worker1
So it turns out this issue was a by product of another configuration issue. We had different Railo contexts configure to point to the same set of shared directories, some of the context's mapped to directories that were within the root context which caused Java thread locks

Apache WSASocket failed to open the inherited socket. (LMHOSTS disabled)

[Thu Aug 09 11:20:30 2012] [notice] Child 4656: Child process is running
[Thu Aug 09 11:20:30 2012] [crit] (OS 10022)An invalid argument was supplied. : Child 4656: setup_inherited_listeners(), WSASocket failed to open the inherited socket.
[Thu Aug 09 11:20:30 2012] [crit] Parent: child process exited with status 3 -- Aborting.
I have started getting this error unexpectedly. I dont believe I changed any conf files.
Are there are any temporary files I can reset in the apache installation? I have moved everything from /xampp/tmp
I have checked to see if localhost:80 is in use, I dont think this is the case.
I have reset netsh as specified here: https://issues.apache.org/bugzilla/show_bug.cgi?id=31765
Please recommend steps to reset apache as I believe it is possible this is an issue caused by a orphaned PID or something of that nature as nothing has changed and I do unexpected shutdowns of my computer.
This is on Windows XP, apache httpd.exe version is 2.2.11.0
Port 443 was in use. Then magically ceased being in use. Then I guess perhaps netsh reset caused LMHOSTS to be enabled because I ended up with Local Connection being renamed to Local Connection 2 with LMHOSTS enabled. This is called magic.
Panda Media Booster was using 443.

Apache load balancing not working properly | mod_jk

I have two jboss application server (on different machines and ip address) and I have setup apache as web server for this application server using mod_jk configuration. Apache web server is also setup to load balance between these two application servers.
Following is the content of my workers.properties file:
worker.list=portalworker1,portalworker2,portalbalancer
worker.portalbalancer.type=lb
worker.portalbalancer.balance_workers=portalworker1,portalworker2
worker.portalbalancer.sticky_session=True
# Application server 1 Portal application
worker.portalworker1.type=ajp13
worker.portalworker1.host=10.178.197.91
worker.portalworker1.port=8009
worker.portalworker1.lbfactor=1
# Application server 2 Portal application
worker.portalworker2.type=ajp13
worker.portalworker2.host=10.178.197.90
worker.portalworker2.port=8009
worker.portalworker2.lbfactor=1
The problem is that currently request is being sent to any of the application server (for eg. one request at application server 1 and the second request to application server 2) which will obv. won't work.
I have also checked mod_jk log in debug mode:
For 1st request
[Tue Dec 13 16:46:12.222 2011] [16097:47166030803776] [debug] get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial sessionid UH76jWj-q2yX39prlS-nBA**
[Tue Dec 13 16:46:12.222 2011] [16097:47166030803776] [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best worker portalworker2 (portalworker2) using method 'Request'
For 2nd request:
[Tue Dec 13 16:46:12.434 2011] [16100:47166030803776] [debug] get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial sessionid UH76jWj-q2yX39prlS-nBA**
[Tue Dec 13 16:46:12.434 2011] [16100:47166030803776] [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best worker portalworker1 (portalworker1) using method 'Request'
This also ensures that the sessionid's for 2 requset are same, still different workers are found.
Any idea what I am doing wrong?
The problem was that I had not added jvmRoute in my server.xml for my different application server to differentiate these servers, and also useJK was not set to true in jboss-service.xml file.