Skip to main content

Observations on DataLoader

1 reply [Last post]
Anonymous

The dataloader api is ambiguous in the loadMetaData method about what an
implementation should do if no metadata is available until the entire stream
has been read.

The startLoading method may benefit from having a thread pool to work with.
For an application that is sending data back and forth constantly, it might
be nicer to have a thread pool than to spin up 10 threads every time a new
window is opened. This can be achieved either by providing an abstract
method in the startLoading class called 'getWorkerThread' or something and
let extending classes decide what to do about it. Or, perhaps, a method
called 'runWorker(Runnabled run)' that would allow the concrete
implementation do what it will with the runnable (such as passing it off to
an Executor).

The dataLoader is not flexible enough in its loadMetaData(Object model,
InputStream is), startLoading(final Object model, final InputStream is), and
possibly readData(InputStream is) methods.

Consider the following situation: The data you need to load is located on
some remote server. The
DataLoader only deals with inputstreams, so you must create a URL for the
remote site and call
openConnection(). At this point you already have 200+ms of delay in the
responsiveness of your
application because the URL opened a socket connection to the remote host on
the event dispatch
thread! Furthermore, in Java 1.5 if you specifiy a host name like
"192.168.1.9" in the Socket
constructor, the code tries to do a reverse host name lookup before opening
the connection (to revent spoofing, I suppose). In an environment where the
name does not resolve because there is no authoritative DNS server, the 'new
Socket(host, port)' call hangs for about a second and a half. And according
to DataLoader, this must be done *before* the data loading thread is called.

Solution: Either craft an interface representing an input stream that hasn't
been opened yet, or allow 'Object source' to be the parameter passed to the
methods. Let the concrete implementations handle the details. The interface
approach is most likely the wisest choice.

Richard

PS> Of course, I am working on implementations of these ideas to see how
well they work. I'll let you know.

_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page ? FREE
download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mark Davidson

Hi Richard,

Thanks for your thoughts on this matter. We are really busy with JavaOne
right now and may not be fully engaged for another couple of weeks.

I'll try to address your query right now but this is definitely a
discussion that warants a detailed discussion.

On 06/26/2004 03:06 PM, Richard Bair wrote:
> The dataloader api is ambiguous in the loadMetaData method about what an
> implementation should do if no metadata is available until the entire
> stream has been read.

http://javadesktop.org/jdnc/0_5/docs/api/org/jdesktop/swing/data/DataLoa...

I found an archived discussion that we had on the topic back in November
'03 but the implementation has change since. Amy can probably give a
more detailed answer on this topic.

>
> The startLoading method may benefit from having a thread pool to work
> with. For an application that is sending data back and forth constantly,
> it might be nicer to have a thread pool than to spin up 10 threads every
> time a new window is opened. This can be achieved either by providing an
> abstract method in the startLoading class called 'getWorkerThread' or
> something and let extending classes decide what to do about it. Or,
> perhaps, a method called 'runWorker(Runnabled run)' that would allow the
> concrete implementation do what it will with the runnable (such as
> passing it off to an Executor).

This sound a lot like a WorkQueue and yes this would be a great features
to have. We have a WorkQueue implementation that we would like to check
into the work space:

http://java.sun.com/blueprints/code/jps132/src/com/sun/j2ee/blueprints/a...

Does this satisfy your requirements? Would this be a good basis to
explore the implemtation of WorkQueues/ThreadPools?

> The dataLoader is not flexible enough in its loadMetaData(Object model,
> InputStream is), startLoading(final Object model, final InputStream is),
> and possibly readData(InputStream is) methods.
>
> Consider the following situation: The data you need to load is located
> on some remote server. The
> DataLoader only deals with inputstreams, so you must create a URL for
> the remote site and call
> openConnection(). At this point you already have 200+ms of delay in the
> responsiveness of your
> application because the URL opened a socket connection to the remote
> host on the event dispatch
> thread! Furthermore, in Java 1.5 if you specifiy a host name like
> "192.168.1.9" in the Socket
> constructor, the code tries to do a reverse host name lookup before
> opening the connection (to revent spoofing, I suppose). In an
> environment where the name does not resolve because there is no
> authoritative DNS server, the 'new Socket(host, port)' call hangs for
> about a second and a half. And according to DataLoader, this must be
> done *before* the data loading thread is called.

You have a great understanding of network connectivity issues. Ideally,
we want to have all network calls on a new thread with status
notification on the EDT. In this situation, new Socket(..) should be
executed on a separate thread and the status of the operation should
trigger the data loading thread if the connection was successfull.

>
> Solution: Either craft an interface representing an input stream that
> hasn't been opened yet, or allow 'Object source' to be the parameter
> passed to the methods. Let the concrete implementations handle the
> details. The interface approach is most likely the wisest choice.
>
> Richard
>
> PS> Of course, I am working on implementations of these ideas to see how
> well they work. I'll let you know.

I'm looking forward to this!

Thanks for your input.

--Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net