DEV Community: jeevan wijerathna

Configuring Tomcat in Azure App Service: Increase maxParameterCount

jeevan wijerathna — Mon, 02 Jun 2025 23:36:29 +0000

When hosting Java web applications on Azure App Service using Tomcat, you might encounter issues with legacy Java applications due to the default maxParameterCount limit (1000). For legacy applications handling large forms or query strings, this limit can block expected behavior and cause request failures.

In this guide, I'll walk you through a quick and effective way to increase the maxParameterCount parameter to 10000 using a custom startup script in Azure App Service.

Understanding the Problem

By default, Tomcat sets a limit of 1000 parameters that can be processed in a single HTTP request. This includes:

Form fields in POST requests
URL parameters in query strings
Multiple values for the same parameter name

When your application exceeds this limit, Tomcat will ignore additional parameters, potentially breaking your application's functionality without clear error messages.

Solution: Custom Startup Script

We'll create a startup script that:

Modifies the server.xml configuration file
Updates the maxParameterCount value
Starts Tomcat with the new configuration

Step 1: Create a Startup Script

There are several ways to create and upload the startup script to your Azure App Service:

Option 1: Using the Kudu Console (Azure App Service Advanced Tools)

Navigate to your Azure App Service in the Azure Portal
Go to Development Tools > Advanced Tools > Go
In the Kudu console, click on Debug console > SSH
Navigate to the /home directory
Click on the + button > New File and name it startup.sh
Copy and paste the following script:

#!/bin/bash

# Update maxParameterCount from 1000 to 10000 in server.xml
set -e

SERVER_XML="/usr/local/tomcat/conf/server.xml"
NEW_VALUE="10000"

echo "[$(date)] Starting Tomcat configuration update..."

# Backup original file
cp "$SERVER_XML" "${SERVER_XML}.backup"
echo "[$(date)] Backup created."

# Update value
sed -i 's/maxParameterCount="1000"/maxParameterCount="'"$NEW_VALUE"'"/g' "$SERVER_XML"
echo "[$(date)] Updated maxParameterCount to $NEW_VALUE"

# Verify update
if grep -q "maxParameterCount=\"$NEW_VALUE\"" "$SERVER_XML"; then
    echo "[$(date)] Configuration update successful"
else
    echo "[$(date)] ERROR: Update failed, restoring backup"
    cp "${SERVER_XML}.backup" "$SERVER_XML"
    exit 1
fi

# Start Tomcat
echo "[$(date)] Starting Tomcat..."
exec catalina.sh run

Save the file
In the SSH console, run:

   chmod +x /home/startup.sh

Option 2: Using FTP/FTPS

Set up FTP/FTPS credentials in your App Service (under Deployment Center > FTPS credentials)
Create the script locally on your computer
Upload the file to the /home directory using your preferred FTP client (like FileZilla)
Connect to the Kudu SSH console as described above and run:

   chmod +x /home/startup.sh

Option 3: Using Azure CLI

Create the script locally on your computer (e.g., startup.sh)
Use Azure CLI to upload it:

   # Login to Azure
   az login

   # Set your subscription (if you have multiple)
   az account set --subscription <your-subscription-id>

   # Upload the file to the App Service
   az webapp deploy --resource-group <your-resource-group> --name <your-app-name> --src-path startup.sh --target-path /home/startup.sh

   # Connect to the App Service using SSH
   az webapp ssh --resource-group <your-resource-group> --name <your-app-name>

   # Inside the SSH session, make the script executable
   chmod +x /home/startup.sh

This script performs the following operations:

Creates a backup of the original configuration file
Uses sed to replace the default value with our new value
Verifies the change was successful
Starts Tomcat with the updated configuration

Step 2: Configure App Service to Use the Script

Navigate to your Azure App Service in the Azure Portal
Go to Configuration > General settings
In the Startup Command field, enter: /home/startup.sh
Click Save

Verification and Testing

After deploying your changes:

Check the application logs in Log stream to verify the script executed successfully
Look for messages like: [date] Updated maxParameterCount to 10000 and [date] Configuration update successful
Test your application with a request that contains more than 1000 parameters

Important Considerations

Always test configuration changes in a staging slot before deploying to production
This approach assumes you're using Tomcat on Linux in Azure App Service
The exact path to server.xml may vary depending on your Tomcat version and configuration
Consider security implications of increasing this limit, as very large requests could potentially be used in DoS attacks

Conclusion

By implementing this custom startup script, you can easily increase Tomcat's maxParameterCount to handle larger requests in your Azure App Service. This approach ensures the configuration is applied consistently each time your application starts, avoiding the need for manual intervention after deployments or service restarts.

For more complex scenarios or additional Tomcat configuration needs, you might consider creating a custom Docker image with your preferred settings pre-configured.

Dynamically Populating Parameters in Manual GitHub Action

jeevan wijerathna — Thu, 21 Mar 2024 21:11:25 +0000

Overview

When manually running a GitHub Action with configured choice parameters, it's ideal to have the values dynamically generated and displayed in a drop-down menu. This can be accomplished by creating a GitHub Action that updates the parameters in the YAML file of the main action whenever changes are pushed.

GitHub Action to Update YAML File

Here is a GitHub Action designed to populate the option values:

name: 'Populate option values'

on:
  push:
    branches:
      - 'main'

jobs:
  eslint:
    name: Populate Option Values
    runs-on: ubuntu-latest
    steps:
      - name: Check out Code
        uses: actions/checkout@v2
        with:
          token: ${{ secrets.GH_TOKEN }}

      - name: Run Populator
        run: ./scripts/populate-option-value.sh

      - name: Commit Changes
        run: |
          if git diff --quiet; then
            echo "ℹ️ No new Component names to update"
          else
            git config --global user.email "${{ github.actor }}@email.com }}"
            git config --global user.name "${{ github.actor }}"
            git status
            git add .github/workflows/release-it.yml
            git commit -m "✅ Populated option values"
            git push
          fi

Note: You'll need to create a GitHub Personal Access Token (PAT) with push permissions, as the default GitHub PAT does not allow changes to be pushed from the GitHub Action. This should be configured as a secret in your repository.

Populator Script

A script is used to read the current parameter values, compare them to the dynamic values, and update the YAML file if they differ:

Note: here I use yq to manipulate YAML. Further you need to allow GH Action to run the script otherwise you will get Permision Denied error when run Action.

git update-index --chmod=+x your_script.sh

#!/bin/bash

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
SOURCE_YAML_FILE="$SCRIPT_DIR/../.github/workflows/target-action.yml"

# dynamically generate values.
# ex. could read repository or file to get values
OPTIONS=(major minor patch prerelease)

current_options=$(yq eval '.on.workflow_dispatch.inputs.version.options' $SOURCE_YAML_FILE )

current_options_array=()
while read -r word; do
    current_options_array+=("$word")
done <<< "$current_options"

declare -a output_array=()

for i in $OPTIONS; do
    output_array+=("$i")
done

# Check if the values in the arrays are equal
if [[ "${current_options_array[*]}" == "${output_array[*]}" ]]; then
    echo "Values in YAML file are equal to values in array. No update needed."
else
    echo "Values in YAML file are not equal to values in array. Updating YAML file."
    # Construct YAML-compatible string
    options_string="["

    for option in "${output_array[@]}"; do
        options_string+="\\"$option\\", "
    done

    options_string="${options_string%, }]"

    yq eval ".on.workflow_dispatch.inputs.version.options = $options_string" $SOURCE_YAML_FILE > temp.yml && mv temp.yml $SOURCE_YAML_FILE
fi

The action file with the choice parameter might look like this:

name: 'Release'
on:
  workflow_dispatch:
    inputs:
      version:
        type: choice
        options:
          - 'major'
          - 'minor'
        required: true
        default: 'patch'
jobs:
  release:
    runs-on: [ubuntu-latest]
    name: Release it
    environment: NPM_Feed
    steps:
      - name: Check out Code
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

When the populator action is triggered (any changes pushed to the branch), it will execute the script, populate the target action YAML, and create a commit pushing the changes. The updated YAML might look like this:

name: 'Release'
on:
  workflow_dispatch:
    inputs:
      version:
        type: choice
        options:
          - 'major'
          - 'minor'
                    - 'patch'
          - 'prerelease'
        required: true
        default: 'patch'
jobs:
  release:
    runs-on: [ubuntu-latest]
    name: Release it
    steps:
      - name: Check out Code
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      .......

This strategy allows for dynamic population of choice parameters in your GitHub Actions.

Cleansing the Code - Mastering Single File Reversion in Git

jeevan wijerathna — Tue, 23 May 2023 07:29:59 +0000

Problem

When collaborating with other developers, making changes to files unrelated to your pull request for testing purposes can lead to messy commit histories. Manually undoing those changes line by line and creating new commits is time-consuming and cumbersome. To tackle this problem, knowing how to revert a single file to a specific commit in Git becomes crucial. This allows for cleaner handling of unrelated file changes, maintaining a streamlined commit history, and efficient code testing and collaboration.

Step 1: Find the Commit ID

Run the following command, replacing <path/to/file> with the actual path to the file you're interested in:

git log --follow -- <path/to/file>

Step 2: Revert the File

Open a terminal and navigate to the working directory.
Use the following command to revert the file, replacing [commit ID] with the actual commit ID and path/to/file with the file path:

git checkout [commit ID] -- path/to/file

Example Scenario
Let's consider a scenario where you accidentally introduced a line break in a file named src/js/script.js while making other changes. The file originally had correct formatting. To revert the file to its previous state:

Find the Commit ID:

git log --follow -- src/js/script.js

Take note of the commit ID.
Example ec3c5c5fe7efae1846840758d26628529a3ccd8b

Revert the File

git checkout ec3c5c5fe7efae1846840758d26628529a3ccd8b -- src/js/script.js

This command reverts the src/js/script.js file to the state it was in at commit ec3c5c5fe7efae1846840758d26628529a3ccd8b, removing the accidental line break.

Commit the Change: Commit the reverted file using the standard commit command:

git commit -m 'Revert accidental line break in script.js'

Push the Commit: Push the commit to the remote repository to synchronize your branch with the remote version:

git push origin branch-name

Following these steps, you can effectively revert a single file to a specific commit in Git, restoring its previous state and ensuring the code functions correctly.

Happy Coding :)

SQL Server Database Partitioning

jeevan wijerathna — Mon, 13 Jun 2022 02:03:21 +0000

What is database table partitioning?

By Default Data of a table reside in one filegroup called Primary. Partitioning enables divide large table into units that may be spread across more than one filegroup in a database and offer fast ways to load and remove large amounts of data from a table. By splitting into smaller units, queries that access only a fraction of the data can run faster because there is less data to scan.

Benefits of Partitioning

Aid in Maintenance of Large Table

Perform maintenance operations quickly because operations target only subsets of data instead of the whole table.

We can transfer or access subsets of data quickly and efficiently while maintaining the integrity of a data collection.

Ex.
Loading data to the table (ETL)

Reduce overall response time to read and load data

Queries may be improved as the query might only scan a specific partition or partitions instead of the entire Table.

Types of Partition

Vertical Partition

The table will be divided into multiple Tables based on columns.

Horizontal Partition

The Table will be divided into multiple with the same number of Columns with a fewer number of rows.

Create Horizontal partitioning in SQL server.

Create Test DB and Test Table

   CREATE DATABASE PartitionTest

   GO

   USE PartitionTest

   CREATE TABLE Orders
       (
         OrderID INT IDENTITY NOT NULL,
         OrderDate DATETIME NOT NULL ,
         OrderMonth INT NOT NULL
       );

Create the partition function

Create Partition function. Defines the number of Partitions. We need to have a column(Partition Column) of Table or index that will be used by partition functions to create and populate partitions. Each value in the partitioning column is an input to the partitioning function, which returns a partition value.

Partitioning Column (OrderMonth)

   CREATE PARTITION FUNCTION PartitionByMonth (INT)
   AS RANGE RIGHT
   FOR VALUES (202201, 202202, 202203);

Create File Group

   --Create File Group
   ALTER DATABASE PartitionTest ADD FILEGROUP FGJan
   GO
   ALTER DATABASE PartitionTest ADD FILEGROUP FGFeb
   GO
   ALTER DATABASE PartitionTest ADD FILEGROUP FGMarch
   GO

Add files to the filegroups

   --Create files and attach to File Group
   ALTER DATABASE PartitionTest
   ADD FILE
   (
     NAME = [File_Month_Jan],
     FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\File_Month_Jan.ndf',
       SIZE = 5 MB,
       MAXSIZE = UNLIMITED,
       FILEGROWTH = 10 MB
   ) TO FILEGROUP FGJan

   ALTER DATABASE PartitionTest
   ADD FILE
   (
     NAME = [File_Month_Feb],
     FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\File_Month_Feb.ndf',
       SIZE = 5 MB,
       MAXSIZE = UNLIMITED,
       FILEGROWTH = 10 MB
   ) TO FILEGROUP FGFeb

   ALTER DATABASE PartitionTest
   ADD FILE
   (
     NAME = [File_Month_March],
     FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\File_Month_March.ndf',
       SIZE = 5 MB,
       MAXSIZE = UNLIMITED,
       FILEGROWTH = 10 MB
   ) TO FILEGROUP FGMarch

Create the partition scheme

   --Create the partition scheme
   CREATE PARTITION SCHEME OrdersPS
    AS PARTITION PartitionByMonth
    TO ([Primary], FGJan, FGFeb, FGMarch);

Here we have to mention all the filegroups including default Primary File Group.

Query to get available File Groups

   SELECT name AS AvailableFilegroups
     FROM sys.filegroups
     WHERE type = 'FG'

Create/Update Table with Partitioning

   --Create Index
   CREATE CLUSTERED INDEX IX_Orders ON [dbo]. [Orders]
   (
      [OrderMonth]
   )WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON OrdersPS(OrderMonth)

Verify partitions with Row Count

   SELECT p.partition_number AS PartitionNumber,
          f.name             AS PartitionFilegroup,
          p.rows             AS NumberOfRows
   FROM sys.partitions p
            JOIN sys.destination_data_spaces dds ON p.partition_number = dds.destination_id
            JOIN sys.filegroups f ON dds.data_space_id = f.data_space_id
   WHERE OBJECT_NAME(OBJECT_ID) = 'Orders'

| PartitionFilegroup | PartitionNumber | NumberOfRows |
| ------------------ | --------------- | ------------ |
| PRIMARY | 1 | 0 |
| FGJan | 2 | 0 |
| FGFeb | 3 | 0 |
| FGMarch | 4 | 0 |

Insert Test Data

   INSERT INTO PartitionTest.dbo.Orders (OrderDate, OrderMonth)
   VALUES (N'2022-01-18 17:25:05.000', 202201);

   INSERT INTO PartitionTest.dbo.Orders (OrderDate, OrderMonth)
   VALUES (N'2022-02-18 17:25:39.000', 202202);

   INSERT INTO PartitionTest.dbo.Orders (OrderDate, OrderMonth)
   VALUES (N'2022-03-18 17:25:58.000', 202203);

We can see rows are distributed among each file groups

| PartitionFilegroup | PartitionNumber | NumberOfRows |
| ------------------ | --------------- | ------------ |
| PRIMARY | 1 | 0 |
| FGJan | 2 | 1 |
| FGFeb | 3 | 1 |
| FGMarch | 4 | 1 |

Complete Query

CREATE DATABASE PartitionTest

GO

USE PartitionTest

CREATE TABLE Orders
(
    OrderID    INT IDENTITY NOT NULL,
    OrderDate  DATETIME     NOT NULL,
    OrderMonth INT          NOT NULL
);

CREATE PARTITION FUNCTION PartitionByMonth (INT)
    AS RANGE RIGHT
    FOR VALUES (202201, 202202, 202203);

--Create File Group
ALTER DATABASE PartitionTest ADD FILEGROUP FGJan
GO
ALTER DATABASE PartitionTest ADD FILEGROUP FGFeb
GO
ALTER DATABASE PartitionTest ADD FILEGROUP FGMarch
GO
--Create files and attach to File Group
ALTER DATABASE PartitionTest
    ADD FILE
        (
            NAME = [File_Month_Jan],
            FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\File_Month_Jan.ndf',
            SIZE = 5 MB,
            MAXSIZE = UNLIMITED,
            FILEGROWTH = 10 MB
            ) TO FILEGROUP FGJan

ALTER DATABASE PartitionTest
    ADD FILE
        (
            NAME = [File_Month_Feb],
            FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\File_Month_Feb.ndf',
            SIZE = 5 MB,
            MAXSIZE = UNLIMITED,
            FILEGROWTH = 10 MB
            ) TO FILEGROUP FGFeb

ALTER DATABASE PartitionTest
    ADD FILE
        (
            NAME = [File_Month_March],
            FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\File_Month_March.ndf',
            SIZE = 5 MB,
            MAXSIZE = UNLIMITED,
            FILEGROWTH = 10 MB
            ) TO FILEGROUP FGMarch

GO

--Create the partition scheme
CREATE PARTITION SCHEME OrdersPS
    AS PARTITION PartitionByMonth
    TO ([Primary],FGJan, FGFeb, FGMarch);

--Create Index
CREATE CLUSTERED INDEX IX_Orders ON [dbo].[Orders]
    (
     [OrderMonth]
        ) WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON OrdersPS(OrderMonth)

-- Insert Test Data
INSERT INTO PartitionTest.dbo.Orders (OrderDate, OrderMonth)
VALUES (N'2022-01-18 17:25:05.000', 202201);

INSERT INTO PartitionTest.dbo.Orders (OrderDate, OrderMonth)
VALUES (N'2022-02-18 17:25:39.000', 202202);

INSERT INTO PartitionTest.dbo.Orders (OrderDate, OrderMonth)
VALUES (N'2022-03-18 17:25:58.000', 202203);

-- View File Groups
SELECT name AS AvailableFilegroups
FROM sys.filegroups
WHERE type = 'FG'

-- View Row counts of Partitions
SELECT p.partition_number AS PartitionNumber,
       f.name             AS PartitionFilegroup,
       p.rows             AS NumberOfRows
FROM sys.partitions p
         JOIN sys.destination_data_spaces dds ON p.partition_number = dds.destination_id
         JOIN sys.filegroups f ON dds.data_space_id = f.data_space_id
WHERE OBJECT_NAME(OBJECT_ID) = 'Orders'