Where to set value of maxHttpHeaderSize?

We are facing following error after the server is started and the site tries to load:

[INFO] [talledLocalContainer] 11.03.2020 15:53:28 WARN  http-nio-8080-exec-4 [AggregationValve.writeAggregatedOutput:547] Exception during flushing the response state. org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write more data to the response headers than there was room available in the buffer. Increase maxHttpHeaderSize on the connector or write less data into the response headers.
[INFO] [talledLocalContainer] 11-Mar-2020 15:53:28.656 SEVERE [http-nio-8080-exec-4] org.apache.coyote.http11.Http11Processor.service Error processing request
[INFO] [talledLocalContainer] 	org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write more data to the response headers than there was room available in the buffer. Increase maxHttpHeaderSize on the connector or write less data into the response headers.

We have increased set the value of maxHttpHeaderSize in starterstore-boot/conf/server.xml. However, it doesn’t take effect unless we change directly in the target folder. The target folder is not included in the distribution package for deployment.

Could someone help us get around this?

Thanks.

Hi,
can you please check if files below src/main/assembly/ refer somehow to the conf/server.xml?

Hi @giacomolm

I can’t see any reference to conf/server.xml below src/main/assembly/.

Although what I did was update the cargo.run in the main pom.xml and included a reference to conf/server.xml to replace.

<tomcat.server-xml>${project.basedir}/conf/server.xml</tomcat.server-xml>
...
...
<profile>
      <id>cargo.run</id>
      <build>
        <plugins>
          <plugin>
           ...
            <configuration>
              <configuration>
                <configfiles>
                  <configfile>
                    <file>${tomcat.server-xml}</file>
                    <todir>conf/</todir>
                    <tofile>server.xml</tofile>
                  </configfile> 
...
</profile>

I verified that it works on a local environment replacing target/tomcat9x/conf/server.xml with conf/server.xml and the issue is gone. However, this change doesn’t seem to take effect after deploying distribution to the cloud.

Hi,

I have also tried setting directly using cargo.run property:

            <properties>
              <cargo.tomcat.connector.maxHttpHeaderSize>65536</cargo.tomcat.connector.maxHttpHeaderSize>
            </properties>

This also works on local but not on cloud when deployed using a distribution.

Can you please look into this?

Hi @giacomolm ,

Adding a reference to server.xml in src/main/assembly/conf-component.xml also not working:

<file>
      <source>conf/server.xml</source>
      <outputDirectory>conf</outputDirectory>
      <destName>server.xml</destName>
    </file>

Thanks
Ravinder

Hi,
please make sure that the conf-component.xml descriptor is included in the distribution-*.xml used.

Once the distribution is created, your server.xml should be part of the distribution created, more specifically under the conf/ folder. You can unpack the distribution locally and check it.

While deploying the distribution in your tomcat folder, please ensure that the distribution conf/ folder is merged with your tomcat (HOME) conf/ folder. IIRC, in case your tomcat installation is distributed in 2 folders (BASE and HOME), the configuration defined in the HOME folder should be preferred. In other words, your custom server.xml copied in our CATALINA_HOME/conf folder should be used by tomcat.

Please let us know if that’s not the case, thanks!

Hi @giacomolm,
conf-component.xml descriptor is part of distribution-*.xml and the distribution created has conf/ folder including server.xml in it.

However, how can we make sure that the conf/ folder in disctribution is merging with tomcat because we only have access to deploy using Mission Control and don’t have access to tomcat installation. Do you think we can raise this with our point of contact in BloomReach?

Rav

Hi,
I see, in this case it’s up to brCloud indeed. I think it would be great if you get in touch with Bloomreach support in this case.

HTH,
Giacomo