search

structurizr / onpremises

Structurizr on-premises installation
https://docs.structurizr.com/onpremises
MIT License
117 stars 45 forks source link

API timeout when putting workspace #67

Closed vedeja closed 6 months ago

vedeja commented 9 months ago

Description

When using the CLI to push a workspace to the structurizr/onpremises:3142 API, the request times out and the CLI logs ""java.net.SocketTimeoutException: Read timed out". Even though this error is logged, the UI is updated with the new workspace, and seems to be working fine from that perspective.

Steps to reproduce

  1. Run structurizr/onpremises:3142 exposed as https://myapp
  2. docker run --rm -v myfolder:/usr/local/structurizr structurizr/cli push -url https://myapp/api -id 1 -key mykey -secret mysecret -workspace workspace.json -merge false -archive false

Expected result:

Actual result:

Screenshot

No response

Code sample

No response

Configuration

No response

Severity

Minor

Priority

Low

Resolution

I have no budget and there's no rush, please fix this for free

More information

No response

simonbrowndotje commented 9 months ago

I am unable to reproduce this, so it's likely related to something in your environment ... either the size/content of your workspace, or whatever tech you're using to route traffic to the app via https://myapp.

danhan79 commented 9 months ago

I found that the default search setting, lucene, takes a long time to index and the structurizr cli times out.

vedeja commented 9 months ago

Setting structurizr.search=none appears to help. But of course leaves us with no search feature.

vedeja commented 9 months ago

I’m also curious about if pushing the workspace basically immediately after starting structurizr is part of the potential lucene overload.

simonbrowndotje commented 9 months ago

Lucene indexing is almost instantaneous on my laptop, even for large workspaces, so I would install the on-premises installation locally (i.e. on your computer) to see if you experience the same performance issues. I imagine they are related to something in your environment (network performance, how the file system has been mounted, etc).

andrey-dubnik commented 8 months ago

For me the solution was in removing the write.lock from the index directory. Seem on some stage JVM crashes leaving the lock file and the only way is to clean it manually as JVM won't know if this is safe to do so.

Removing the lock on the app startup could fix the issue considering there is only one process.

simonbrowndotje commented 6 months ago

I suspect this is environment/configuration related, but you're welcome to reopen if with details on how to reproduce it.