Xlog Day 3, Work Log - Why is Apollo Configuration Center sometimes effective and sometimes not effective?

Here, I would like to add a few words about Mr. Li Qingchen's article mentioned yesterday. His writing is simple but powerful, and it gives people the courage to move forward even when they know the road ahead is dark. I recommend it to everyone.

Today, I actually learned a bit about network protocols. Originally, I wanted to name my blog "The Network Apprentice - What is ifconfig?" However, because I encountered a very confusing and frustrating problem at work today, I changed it to "Work Log - Why is Apollo Configuration Center sometimes effective and sometimes not?"

I am a Java developer and currently responsible for a scheduled task project at the company. In this project, I use the Java ScheduledThreadPoolExecutor with a delay queue to schedule tasks (some experts might ask me why I use this when there are so many ready-made frameworks available, but unfortunately, this is the only one I know 😂). Here is a simple list of its methods:

public ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit);

The above is the method I use. Some of you may not understand it, but that's okay. What I want to do now is to extract the second parameter in the parentheses and make it a variable that can be changed at any time. So I use Apollo, a configuration center, which allows us to store commonly used and potentially changing parameters in Apollo. When our project is running on the server, we can modify these parameters without frequently restarting the project.

I successfully integrated Apollo according to the integration document provided by the company and the official documentation. I also successfully retrieved the configuration. Here comes the problem:

After I published all the configurations, the project started and was able to read all the configurations from the configuration center and run and execute tasks normally. When I first tried to modify some parameters in the configuration center and republished them, the project was able to immediately obtain the modified values. At this point, I only tested it once, which means I only modified the configuration center once, and it could be one or two parameters. Everything was normal.

However, when I tried to modify the configuration again, the logs showed that Apollo had obtained the modified values, but the project still obtained the original parameter values. For example, the initial value of "time" was 10s, and when I first modified it to 15s, the project ran normally. But when I modified it back to 10s for the second time, the project still obtained 15s as the value. Even if I made further modifications, the value remained at 15s. In other words, I can only modify the configuration once. It's very strange.

I added a listener in the local code, like a monitor, to monitor the changes in the remote configuration center. At this point, I obtained the correct values, which means that the monitor obtained the latest values every time I modified the configuration. However, when passed to the project variables, they reverted back to the old values. I didn't debug step by step today, but I plan to try it tomorrow. In addition, I also checked the cache file of the local Apollo configuration, and the values inside were also new. This completely frustrated me. I need to criticize myself.

I think Java developers may have more troubleshooting methods than I can think of. If you have encountered similar problems or have any ideas, please leave me a message to help me solve this problem.

2. What is ifconfig?#

Seeing this title, many people might laugh at me and wonder why I'm developing if I don't even know what this is.

To be honest, I only know that the ifconfig command is used to view the IP address of a computer, at least until today.

ifconfig is a command-line tool used to configure and control network interfaces in Linux/Unix systems. It allows us to enable/disable network interfaces, configure IP addresses, subnet masks, broadcast addresses, etc.

Until today, I only used it to view IP addresses, and I haven't used the other four functions.

Here is a brief summary:

The network interfaces we often talk about are usually named as eth0, eth1, etc., and the commonly used options are:

up/down: Enable/disable network interfaces. For example, ifconfig eth0 up.
ip: Configure the IP address of the interface. For example, ifconfig eth0 192.168.1.10.
netmask: Configure the subnet mask. For example, ifconfig eth0 netmask 255.255.255.0.
broadcast: Set the broadcast address. For example, ifconfig eth0 broadcast 192.168.1.255.
mtu: Set the MTU value, which stands for Maximum Transmission Unit. For example, ifconfig eth0 mtu 1500.

The above involves abbreviations for many terms, and I also looked up their meanings:

eth0, eth1: eth0 and eth1 are the naming conventions for network interfaces in Linux systems. "eth" stands for Ethernet, and 0 and 1 are interface numbers. So eth0 and eth1 both represent an Ethernet network card, but with different numbers for distinction.
IP (Internet Protocol): It is used to describe the rules for transmitting data on the Internet. An IP address is used to locate a device on the network, allowing data packets to be sent to the target device correctly.
- IP defines two types of addresses:
- IPv4: 32-bit address, usually written as four numbers between 0 and 255, separated by dots, such as 192.168.1.1.
- IPv6: 128-bit address, usually written as eight groups of hexadecimal numbers, separated by colons, such as 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
Netmask: The subnet mask is used in conjunction with an IP address to divide the IP address into network and host portions. It consists of four segments of 32 bits and is used to determine whether hosts are in the same network. By performing a bitwise AND operation between the IP address and the subnet mask, the network address can be extracted. For example (an example I found online 🌰):
1. IP address: 192.168.1.1
2. Subnet mask: 255.255.255.0
Perform a bitwise AND operation between 192.168.1.1 and 255.255.255.0:

192.168.1.1
255.255.255.0
---------------------
192.168.1.0

From the result of the operation, we can see that the network addresses of these two addresses are the same, which is 192.168.1.0. So 192.168.1.1 and the subnet mask 255.255.255.0 are in the same subnet.
Broadcast Address: The broadcast address is the destination address for data packets that can be received by all hosts on the network. It allows the sender to send information to all hosts in the network at once. I looked up how to calculate this broadcast address online, but I haven't fully understood it yet, so I won't write about it for now. Its functions are:
1. Allows all hosts in the network to receive the same data packet, achieving broadcast communication.
2. Used for the ARP protocol to resolve IP addresses into MAC addresses. When a host needs to send an ARP request, it sets the destination address as the broadcast address, so that all machines in the network can receive the ARP request.
  1. ARP Protocol: ARP (Address Resolution Protocol) is used to resolve IP addresses into MAC addresses for network communication.
    1. MAC Address: (Media Access Control Address) is the physical address of a network card, similar to our human ID card.
3. DHCP protocol uses the broadcast address to allocate IP addresses and other network parameters to all clients.
4. Can be used for network diagnostics and troubleshooting. By sending ICMP broadcast Ping packets, all hosts in the subnet can be checked.
MTU (Maximum Transmission Unit): It specifies the maximum packet size (in bytes) that a network interface can accept.
- The value of MTU depends on the interface type and network medium. Common values include:
  - Ethernet interface commonly uses 1500 bytes.
  - DSL network interface commonly uses 1492 bytes.
  - PPP link commonly uses 1472 bytes.
  - IPSEC VPN tunnel commonly uses 1436 bytes.
There is another knowledge about MTU: Regardless of the MTU of the receiving side, the sending side cannot send packets larger than its own MTU. In other words, the size of the sent data packet is determined by the side with the smaller MTU.

The above content is the new knowledge I learned yesterday and today, at least for me. I'm recording it.

3. Recent News#

I have read a lot of news recently, but it seems like I haven't really read any news. The ones I want to delve into are not visible, only cold blue text on a white background. The ones I don't want to delve into are everywhere, floating around whether I open my phone or not.

The Lakers lost today, unexpectedly not winning against the Grizzlies, who were missing key players. Some friends said it was a conspiracy between bookmakers and the league, just to make more money.

I don't think so. From watching the entire game today, the Lakers lost in three aspects. First, they didn't match the intensity of the Grizzlies. Their complacency made them careless. Second, Coach Ham's ability to adapt on the spot is indeed questionable. In the first game, using Vanderbilt against Morant had an effect, but in the second game, not using Vanderbilt against Morant exposed Vanderbilt's lack of attacking ability and his weakness in being chased by Dillon Brooks and Jaren Jackson Jr. Third, I don't know what happened to Anthony Davis, he's been performing poorly.

Today, I have so much to say.