Giter Site home page Giter Site logo

Comments (6)

vinipsmaker avatar vinipsmaker commented on June 25, 2024

Can you have a try to give an answer?

I didn't quite understand what is the question. Can you elaborate a little more?

Even if I didn't understand the question, it reminds me of the differences between Tufão 0.x and 1.x.

from tufao.

tnm0113 avatar tnm0113 commented on June 25, 2024

Tks for reply me !!, I have an example here with 2 handlers: Handler1, Handler2

class Handler1 : public Tufao::AbstractHttpServerRequestHandler
{
.......
public slots:
bool handleRequest(Tufao::HttpServerRequest *request,
Tufao::HttpServerResponse *response,
const QStringList &args);
void onEndRequest();
};

class Handler2 : public Tufao::AbstractHttpServerRequestHandler
{
..........
public slots:
bool handleRequest(Tufao::HttpServerRequest *request,
Tufao::HttpServerResponse *response,
const QStringList &args);
void onEndRequest();
};

In slot handleRequest, I have:
connect(request, SIGNAL(end()), this, SLOT(onEndRequest()));

In slot onEndRequest(), I log this:
handler1.cpp: qDebug() << "END ACCESS HANDLER 1";
handler2.cpp: qDebug() << "END ACCESS HANDLER 2";

In main:
router.map(QRegExp("^/handler1"), &hand1)
.map(QRegExp("^/handler2"), &hand2);

So every request comes to handler will go through handleRequest, right? Request to /handler1 comes to handleRequest of Handler1, and request to /handler2 comes to handleRequest of Handler2. And when request ends, it will go to onEndRequest().

First time I request to /handler1. it logs:
"END ACCESS HANDLER 1";

Second time, it logs double:
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";

Third time, it becomes trible:
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";

And request to /handler2, it logs:
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 1";
"END ACCESS HANDLER 2";

It seems the previous requests haven't ended yet. They still emit the signal end() and the handlers still catch this signal.

Can you explain for me this situation ? Tks alot

from tufao.

vinipsmaker avatar vinipsmaker commented on June 25, 2024

Can you explain for me this situation ? Tks alot

Well, this is one of the differences between Tufão 0.x and Tufão 1.x and I used an alternative approach in Tufão 1.x because I acknowledged the lack of intuitiveness:

[In Tufão 1.x] HttpServerRequest::ready signal auto-disconnects all slots connected to the HttpServerRequest::data and HttpServerRequest::end slots before being emitted.

To understand what it is happening, you just need to realize that HttpServerRequest will NOT abstract a single session (i.e. a pair of request and reply). HttpServerRequest will abstract a whole connection. The object is reused for other pairs of requests and replies within the same connection. So, before you're done with the object, you need to unglue all callbacks that you configured before.

Currently, this is what is happening to your code:

  1. A connection is initiated, then a HttpServerRequest object is created.
  2. A request on this connection is ready, so the ready signal is emitted.
  3. On the onReady slot, you add a connection on the data signal.
  4. (Whatever, a lot happens)
  5. A new request is ready on the same connection, so, for the same object, the ready signal is once again emitted.
  6. On the onReady slot, you add a new and fresh connection on the data signal. But this new signal-slot connection is redundant, because there was a previous connection that is identical to the new one. Now, you have two connections and the slot will be called two times.

Was I clear?

Fix: On the onEnd slot, clear all connections that you have made on the onReady slot.

Alternative fix: Use Tufão 1.x, as it will automatically disconnects all slots connected to the HttpServerRequest::data and HttpServerRequest::end slots before emitting the ready signal. I cannot backport these changes to Tufão 0.x because I have a compromise on API stability and the change would break how you use the API.

from tufao.

tnm0113 avatar tnm0113 commented on June 25, 2024

Thank you so so much. Unfortunately, I must use Qt 4.7 so I can't use Tufao 1.x. But if I don't handle the ready signal, how can I clear all previous connections ? Can you give me an example

from tufao.

vinipsmaker avatar vinipsmaker commented on June 25, 2024

But if I don't handle the ready signal, how can I clear all previous connections ?

There isn't much secret here. The trick is to ensure there is only one signal-slot connection. You can even use Qt::UniqueConnection, but I cannot recommend this as a general case because it's very easy to create bugs. You must be careful and understand what you're doing because HTTP is stateless and data artifacts from one pair of request and response must not escape to another unrelated pair of request and response.

Anyway, in handleRequest, just clear all slots connected to the data and end signals before doing anything. But this must be done for the whole project.

Can you give me an example

I'm on the middle of a timeline now, so I cannot give much resources to this issue now. If you remind me on January 2 (or later), I believe I'll have the time to elaborate an example.

from tufao.

tnm0113 avatar tnm0113 commented on June 25, 2024

Thank you, I appreciate it a lot

from tufao.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.