If you are storing state on the server that is needed in order to process an incoming request from the client, then the server is stateful. Said another way, it has state that it stores and needs to access in order to process requests from clients. So, your hashmap is state so your server is stateful.
Now, there are very few real web apps that do rich things that aren't stateful at all. After all, if you're going to have a user login and then process requests on the behest of a logged in client, then somewhat by definition, you're storing state on the server that pertains to a particular client and the server is stateful, even if just for the login info.
So, I wouldn't get too hung up on there being zero state on the server. What matters is how much state is there on the server, how expensive (in terms of processing, storage, etc...) is it to store and access this state and can you still scale your app horizontally with this state. And, wherever practical keep state in the client, not on the server. As a trivial example, suppose you have a client app that has a "next page" button. You could implement "next page" with either client-side state of server-side state.
If you had server-side state for the current page of the client, you could just send a command to the server that you'd like to view the "next" page. The server would look at its state for that client, increment the page and then return the data for the next page.
Or, you could store the current page on the client. When the client wants the next page, it takes its current page number, increments it by one and makes a generic request for the specific page number that it wants to view next.
Which of these implementations do you think scales better? Which is simpler to implement when the user opens a second tab viewing a different page? Which is simpler to horizontally scale. The answer to all of those is the one that does not store the current page on the server, but keeps it in the client and just makes generic requests for page N to the server. Keeping that state client-side makes it easier to scale individually and horizontally and support multiple views for the same client.