You are viewing a plain text version of this content. The canonical link for it is here.

Posted to httpclient-users@hc.apache.org by "Niti Bhatt (PL/EUS)" <ni...@ericsson.com> on 2007/02/02 18:36:38 UTC

RE: Problem using PostMethod (now resolved but causing problem in applet)

Hi Community,
    I was finally able to accomplish the successful transfer of audio
file to the web server over HTTP. I used PostMethod in conjunction with
MultiPartPostMethod to send the data. And it worked fine. But I can only
do this if I am using a standalone application on the client side. I
want to achieve the same through an applet. When I use my jar file
(containing the relevant class files that use HttpClient/PostMethod) in
the <applet> tag, the applet does not get initialized. If I use a
similar jar file without HttpClient code, the applet works fine. Can
someone tell me what can be the issue?

Thanks,
Niti

-----Original Message-----
From: Niti Bhatt (PL/EUS) [mailto:niti.bhatt@ericsson.com] 
Sent: Thursday, February 01, 2007 11:37 AM
To: HttpClient User Discussion
Subject: RE: Problem using PostMethod

Hi Roland,
  I made a local copy of a simple text file and tried to store in
locally in memory and it worked fine. Then I tried using and audio file
and it also got stored in memory locally. But when I tried to send it to
a webserver using URL, URLConnection, and OutputStream, it didn't read
on the server.

I appreciate your help..

Niti 

-----Original Message-----
From: Roland Weber [mailto:http-async@dubioso.net]
Sent: Thursday, February 01, 2007 10:04 AM
To: HttpClient User Discussion
Subject: Re: Problem using PostMethod

Hello Niti,

>    Thanks for your reply. Yes, I also tried sending the plain file 
> without the AudioStream. Still it was not received at the server. I am

> using the setRequestEntity method since setRequestBody is deprecated. 
> Do you think that might be a problem?

No, that is the way you're supposed to do it. Could it be that there is
a problem with the file you are sending? For example that another
process has a lock on the file and it can't be opened because of that?
Try making a copy manually and send the copy.

> After making several attempts, I finally switched to something without

> using HttpClient, i.e. I used URL, URLConnection and OutputStream to 
> write the audio data to the stream. I see that it gets received at the

> server meaning it shows the content length correctly. But when I try 
> to perform a read on the stream, it always returns -1.

The content length is sent in the header, and it seems the file data
isn't sent with HttpURLConnection either. I suspect the problem is on
the client side when reading the file. Have you tried reading it into
memory without sending it?

Consider enabling the wire log for the headers and send us the output:
http://jakarta.apache.org/commons/httpclient/logging.html

hope that helps,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

Re: Is this a good idea?

Posted by Bindul Bhowmik <bi...@gmail.com>.

Steve,

On 2/8/07, Steve Terrell <St...@guideworkstv.com> wrote:
> Folks,
>    I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
>    I just don't see how that will work. I am convinced the singleton
> will have the effect of serializing the requests, since each request
> will only get processed when the singleton gets a time slice from the
> jvm. Am I nuts for thinking the singleton will be a bottleneck?

I am afraid that is not exactly true. If multiple threads are sending
in the requests, the method(s) in the singleton that executes the
request will run in all those threads in parallel. The singleton
however will have to take on the additional overhead of synchronizing
access to any fields in the singleton that get modified during the
request execution, and also for state management (if any).

Regarding the executing in a time slice from the JVM, any
multi-threaded application on a single CPU machine works only on time
slices of the CPU. I don't see how a singleton makes a difference
here.

>
> --Steve
>

Regards,
Bindul

-- 
Bindul Bhowmik
MindTree Consulting Ltd.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

Re: Is this a good idea?

Posted by sebb <se...@gmail.com>.

On 08/02/07, Steve Terrell <St...@guideworkstv.com> wrote:
> Folks,
>   I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
>   I just don't see how that will work. I am convinced the singleton
> will have the effect of serializing the requests, since each request
> will only get processed when the singleton gets a time slice from the
> jvm. Am I nuts for thinking the singleton will be a bottleneck?

[Not sure this is strictly an HttpClient question]

Surely it depends on what the singleton is?

If the singleton is thread-safe without needing sychronisation, then
threads will not impede each other.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

Re: Is this a good idea?

Posted by Julius Davies <ju...@cucbc.com>.

Hi, Steve,

Depends if "synchronized" is used on any of your Singleton's methods.
If not, then your calls will probably not get serialized.

You are right to be concerned about accidental serialization, but you'll
probably be okay this time.  Just test it out.  An easy way to test is:

in the servlet
======================
public void doGet( HttpServletRequest rq, HttpServletResponse rx )
{
  try {
    Thread.sleep( 10000 );
  } catch ( InterruptedException ie ) {}  
}


in the client
======================
Runnable r = new Runnable() {
  public void run() {
    long now = System.currentTimeMillis();
    MySingleton instance = MySingleton.getInstance();
    instance.doHttpCall();
    long duration = System.currentTimeMillis() - now;
    System.out.println( "I took " + duration + "ms" );
  }
};

new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();


If you see results like:

==========================
I took 10028 ms
I took 20121 ms
I took 29994 ms
I took 30001 ms
I took 40014 ms
I took 50512 ms


Then you are accidentally serializing.


yours,

Julius



On Thu, 2007-08-02 at 15:27 -0500, Steve Terrell wrote:
> Folks,
>    I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton. 
>    I just don't see how that will work. I am convinced the singleton
> will have the effect of serializing the requests, since each request
> will only get processed when the singleton gets a time slice from the
> jvm. Am I nuts for thinking the singleton will be a bottleneck?
> 
> 
> 
> --Steve
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
-- 
Julius Davies, Senior Application Developer, Product Development
T 416-652-0183 | juliusdavies@cucbc.com


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

RE: Is this a good idea?

Posted by Roland Weber <RO...@de.ibm.com>.

Hi Steve,

> Well, that's the thing. The HttpState will be wrapped up in the
> singleton. Some of the servers we support will allow up to 32
> simultaneous threads of execution. How will that work when all posts are
> done via a singleton?

The state is required twice for each execution: just before
the request is sent and just after the response header is
received. During the sending and during the response processing,
the state is not accessed and the threads will not synchronize
there.
If you use different HttpClient objects, you will have separate
HttpState objects, too. If that is what you want, you can keep
the HttpClient singleton and have each thread keep it's own state.
That is less overhead than having a connection manager per thread.

hope that helps,
  Roland

RE: Is this a good idea?

Posted by Tatu Saloranta <co...@yahoo.com>.

--- Steve Terrell <St...@guideworkstv.com>
wrote:

> Well, that's the thing. The HttpState will be
> wrapped up in the
> singleton. Some of the servers we support will allow
> up to 32
> simultaneous threads of execution. How will that
> work when all posts are
> done via a singleton?

In addition to conceptual discussion, you might just
want to go ahead and write a simple stress test, with
N threads doing end-to-end requests against a simple
server/service. You can also add artifical latency on
server-side. And on client side, you can try out
difference between singleton approach, and per-thread
instance approach.

Based on discussion so far, there's a good change
there might not be significant difference either way;
and specifically no significant benefit from
non-singleton approach. However, if something was
missing from problem description, this should prove
the problem as well as perhaps also point the
bottleneck (just profile on client side, and/or take
thread dumps during test to see where locking is
done).

It's often a good idea to empirically try out
approaches -- results are regularly surprising as
intuition is not always best guide regarding
performance and scalability.

-+ Tatu +-

____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

RE: Is this a good idea?

Posted by Steve Terrell <St...@guideworkstv.com>.

Well, that's the thing. The HttpState will be wrapped up in the
singleton. Some of the servers we support will allow up to 32
simultaneous threads of execution. How will that work when all posts are
done via a singleton?

--Steve

-----Original Message-----
From: Roland Weber [mailto:ROLWEBER@de.ibm.com] 
Sent: Friday, February 09, 2007 1:14 AM
To: HttpClient User Discussion
Subject: Re: Is this a good idea?

Hello Steve,

>    I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool
of
> choice, of course. The code he is writing must handle multiple
requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton. 

This is exactly how HttpClient is supposed to be used. Each thread
that calls the singleton HttpClient will get it's own connection from
the MTHCM (assuming the connection limits are chosen appropriately).
MTHCM is internally synchronized.
You only have to take care about HttpState. HttpClient holds a single
default HttpState, which is also synchronized internally. If it's OK
for all the threads to share one state, that's fine. Otherwise, each
thread has to keep it's own HttpState and pass it to execute().

hope that helps,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

Re: Is this a good idea?

Posted by Roland Weber <RO...@de.ibm.com>.

Hello Steve,

>    I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton. 

This is exactly how HttpClient is supposed to be used. Each thread
that calls the singleton HttpClient will get it's own connection from
the MTHCM (assuming the connection limits are chosen appropriately).
MTHCM is internally synchronized.
You only have to take care about HttpState. HttpClient holds a single
default HttpState, which is also synchronized internally. If it's OK
for all the threads to share one state, that's fine. Otherwise, each
thread has to keep it's own HttpState and pass it to execute().

hope that helps,
  Roland

Is this a good idea?

Posted by Steve Terrell <St...@guideworkstv.com>.

Folks,
   I think I am losing an argument at work. A coworker is implementing
some code that will be used to call a servlet. HttpClient is the tool of
choice, of course. The code he is writing must handle multiple requests
in parallel, thus he will be using the MultiThreadedConnectionManager.
However, he is proposing to channel all his requests through a
singleton. 
   I just don't see how that will work. I am convinced the singleton
will have the effect of serializing the requests, since each request
will only get processed when the singleton gets a time slice from the
jvm. Am I nuts for thinking the singleton will be a bottleneck?



--Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org