I have a TCP/IP DataSnap server running as a service [Session based LifeCycle] that continuously chews up memory and never comes back to the starting memory size even when there are no connections to it.
In order to eliminate My code as the culprit, I have modeled up a basic TCP/IP DataSnap server running as VCL [Session based LifeCycle] that serves a Server Method class [TDSServerModule] which only contains basic mathematical functions using native data types [no objects to create or free].
When I connect to said DataSnap server with a very thin client I get the same results. The Memory Usage continuously grows with each connection and sporadically grows when executing the server side methods from the client. Once the connections are closed the DataSnap Server never reduces its Memory Usage [even when left running without connections for 8 hrs].
So it seems the best course for you is ending every server method with explicit memory cleanup, if that was possible in XE2. Then you'd better read thosee articles again and prepare for future scalability challenges.
I added the below method and called it from the "TWebModule1::WebModuleBeforeDispatch" event. It eliminated the memory consumption and actually allow the idle REST service to return to a state of no-session memory. DataSnap definitely needs to work on this issue.
You should check the Lifecycle property on TDSServerclass component on your servercontainer. It provides a way to determine the way the session is handled. It defaults to session. Setting it to invokation will free the session after each call (invokation). This will of course mean you have no state. This would be oke in a typical REST server though.
if you still have memory consumption growing. put the following line in your dpr unit. ReportMemoryLeaksOnShutdown := True;
your application will then show you the memory leaks it has on closing of your datasnap server.
I have a very strange situation. I have developed an online ordering app connecting to a Datasnap server. This is the strange part: purely by luck, I found out that when I have a database connection active (by another software) on the server where the datasnap server resides, the app runs very fast; when I don't it is way too slow(er). I use Interbase and Firedac. Does this make sense? Has anyone come across an issue like this? It's like when the database has no connections active, the first connection is taking way too long.
Yes. It's the SessionTimeout of the TDSHTTPWebDispatcher. Currently it's 20 minutes. But again, if that was the problem, I would ALWAYS have the problem; regardless if there is another connection active or not.
This is the strange part: purely by luck, I found out that when I have a database connection active (by another software) on the server where the datasnap server resides, the app runs very fast; when I don't it is way too slow(er).
Com a evoluo de aplicaes em trs camadas, cada vez mais se tem a necessidade de transferir dados entre aplicaes, principalmente com a evoluo rpida dos dispositivos mveis que trouxe uma complexidade a mais, devido a sua diversificao de plataformas e linguagens que as mesmas utilizam. Hoje quem no se adequar a essa realidade, fica ultrapassado no mercado.
Mas muitos podem se perguntar: Como trocar essas informaes entre as aplicaes desenvolvidas em outras linguagens? Essa pergunta nos impe a uma tomada de deciso. Pois temos basicamente dois tipos ou formatos principais de intercmbio de dados, JSON e XML. Mas qual o melhor formato para se encapsular os dados? Vamos analisar esses dois formatos para tomarmos a melhor deciso.
Como podemos ver, a formatao em JSON bem mais simples de lermos e consequentemente vai ficar muito mais fcil para a mquina interpretar, e poder ser at mais rpido para transferir as informaes. Ento j podemos concluir que vamos utilizar JSON para o intercmbio dos dados.
Vamos criar um novo projeto com o wizard do DataSnap que est na pasta DataSnap Server. Clique na opo DataSnap Server e depois em Ok. Ser aberto o wizard onde vamos passar as informaes bsicas de funcionamento do servidor.
Vamos agora adicionar uma aplicao cliente selecionando o Grupo e depois com o boto direito selecionando Add New Project (Figura 5). Selecionar a pasta Delphi Project e depois clica duas vezes em VCL Forms Application, como mostra a Figura 6.
Por padro, ao gerar o proxy no TSQLConnection, gerada uma classe no lado cliente que representa as classes que vo ser consumida no lado cliente com o mesmo nome da classe do servidor concatenado com Client.
Na Listagem 5 est sendo declarada uma varivel da classe representativa da que eu vamos executar no servidor. Em seguida est sendo criado o nosso objeto proxy, para o qual passado no constructor o DBXConnection. Esse objeto funciona como o endereo do servidor. Com o proxy j criado basta chamar o mtodo do servidor, que no nosso caso o mtodo fAloMundo, onde o mesmo retorna um tipo abstrato do tipo TJSONValue o qual possui um mtodo chamado ToString que converte o objeto em JSON para string.
Sua implementao dispensa grandes comentrios, pois sua implementao bastante simples. Esto sendo somados dois valores e em seguida passado para o constructor do TJSONNumber o resultado dessa soma.
Como foi visto nos exemplos anteriores, no existe complicao para trafegar tipos primitivos entre aplicaes cliente/Servidor. Tente por si mesmo descobrir o funcionamento dos outros tipos de objetos JSON, como o TJSONTrue, TJSONFalse, TJSONArray, etc.
Agora vamos consumir esse mesmo servidor no browser para simular um ambiente hbrido. Para poder consumir o nosso servidor no browser vamos ter que adicionar o suporte para HTTP no mesmo. Para isso basta adicionar o componente TDSHTTPService e efetuar as seguintes configuraes conforme a Tabela 4:
Agora vamos executar o mtodo fSomar. Vamos escrever praticamente a mesma URL, mas com a diferena que vamos ter que mudar o mtodo para fSomar e temos que passar os dois parmetros: :1234/datasnap/rest/TSMMetodos/fSomar/10/30.
No existe a necessidade do retorno dos mtodos serem em JSON, pois o DataSnap por padro j faz esse encapsulamento dos tipos, no tendo a necessidade dos retornos serem em JSON, j que internamente esse valores j so convertidos.
A prova disso que os mtodos de exemplos que j foram criados pelo wizard no retornam os valores propriamente em JSON, mas se eles forem ser consumidos no browser, os resultados dos mtodos estaro encapsulados em JSON.
Vamos consumir o mtodo ReverseString para exemplificar o que foi dito anteriormente. Para isso digite a seguinte URL no browser e vamos verificar o resultado em questo: :1234/datasnap/rest/TSMMetodos/ReverseString/Welson
Como foi visto, o resultado do mtodo foi dado em JSON, e isso acontece por que o DataSnap tem a capacidade de fazer essa converso internamente, e mais uma vez o Delphi entra em cena para facilitar a vida dos desenvolvedores.
Como foi visto nesse artigo introdutrio, no complicado realizar a troca de informaes entre aplicaes Cliente/Servidor. Com esses conceitos que foram apresentados nesse artigo j podemos ter uma base para o desenvolvimento de aplicaes hbridas e como foi visto, no existe a necessita de ter muito conhecimento dos tipos em JSON, pois o DataSnap j faz essa converso internamente. Mas claro que sempre bom conhecer o que acontece nos bastidores e foi por isso que neste artigo foi mostrado primeiramente o que acontece internamente, como o DataSnap trata esses dados e s ento foi explicado que o Delphi j faz tudo isso internamente.
7fc3f7cf58