Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2007

Tip: Looking for answers? Try searching our database.

getting null, in object transfer.

Thread view: 
prabodhachyutha@gmail.com - 02 Jul 2007 16:26 GMT
Hi,

I got a problem when sending the data from the serverside and getting
it back in the client side. We are not getting the object(here it is
DataTransferObject which is Serializable) as null in the client side.

I am putting the serverside code.

public void sendDataObjectToClient(
        HttpServletResponse res,
        DataTransferObject obj,
        String accepts) {

        ByteArrayOutputStream bos = null;
        ObjectOutputStream oos = null;
        ServletOutputStream sos = null;
        boolean didCompress = false;
        try {
            sos = res.getOutputStream();
            bos = new ByteArrayOutputStream();
            oos = new ObjectOutputStream(bos);
            oos.writeObject(obj);
            oos.flush();
            oos.close();
            byte[] bytes = bos.toByteArray();
            int origLength = bytes.length;
            if ((bytes.length > 1024 * 2)
                && accepts != null
                && accepts.indexOf("gzip") >= 0) { // large response, compress it.
                ByteArrayOutputStream zbaos = new ByteArrayOutputStream();
                GZIPOutputStream zo = new GZIPOutputStream(zbaos);
                zo.write(bytes);
                zo.flush();
                zo.close();
                bytes = zbaos.toByteArray();
                log.debug(
                    "Writing compressed response, orig="
                        + origLength
                        + " new length="
                        + bytes.length);
                didCompress = true;
            } else {
                log.debug("Writing response, length=" + bytes.length);
            }
            res.setContentType("application/x-java-serialized-object");
            res.setContentLength(bytes.length);
            if (didCompress == true) {
                res.setHeader("Content-encoding", "gzip");
            }
            try {
                sos.write(bytes);
                sos.flush();
            } catch (IOException ioerror) {
                log.info("I/O Error to Client " + ioerror.toString());
            }
        } catch (Exception e) {
            log.error("Unexpected error sending data to client", e);
        } finally {
            if (sos != null) {
                try {
                    sos.close();
                } catch (Exception ignored) {
                }
            }
        }
}

We are using java 1.3 at serverside and 1.4 at the clientside.

And also this problem is not occuring continuously, sometimes we are
getting the object and some times its null. What could be the reason
behind this.

This is very critical for us, any possible solution would be really
helpful for us.

Thanks in advance.
Roedy Green - 03 Jul 2007 01:21 GMT
>We are using java 1.3 at serverside and 1.4 at the clientside.

you can't do that necessarily. Sun's  Objects in general are not
guaranteed to be compatible between Java versions.

You might try generating the stream with Java 1.3 and with 1.4 and
comparing.  Recall that all classes transported must have identical
serialUIDs and identical non-transient fields.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Esmond Pitt - 03 Jul 2007 09:23 GMT
> Recall that all classes transported must have identical
> ... non-transient fields.

This is not so: see the Serialization Specification, section on Versioning.
prabodhachyutha@gmail.com - 03 Jul 2007 11:16 GMT
This problem is not occuring always, only few times the obeject(in
transfer) is becoming null. Did anybody faced this type of issue
earliear?

Please help us.

> > Recall that all classes transported must have identical
> > ... non-transient fields.
>
> This is not so: see the Serialization Specification, section on Versioning.
Roedy Green - 04 Jul 2007 03:50 GMT
>This problem is not occuring always, only few times the obeject(in
>transfer) is becoming null. Did anybody faced this type of issue
>earliear?

you might be having a problem with data not arriving fast enough.

see http://mindprod.com/jgloss/readeverything.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
prabodhachyutha@gmail.com - 09 Jul 2007 16:20 GMT
All,

Thanks for giving some suggestions, now we clearly got the information
on where is the actual problem is.

We are using swing client, where in we are calling the server using
the threads. Here the problem is 1. Two threads are calling the
server
2. Server is sending 2 objects as response(same type)
3. but both threads taking the same object (which is returned last) as
the input(not always)

We are not able to understand, Why this is happening?

What is the best way to resolve this.

On Jul 3, 3:16 pm, prabodhachyu...@gmail.com wrote:
> This problem is not occuring always, only few times the obeject(in
> transfer) is becoming null. Did anybody faced this type of issue
[quoted text clipped - 8 lines]
>
> - Show quoted text -
Nigel Wade - 10 Jul 2007 09:44 GMT
> All,
>
[quoted text clipped - 11 lines]
>
> What is the best way to resolve this.

Given that brief description my first assessment would be that you have a thread
symchronization problem in your servlet. It sounds like you are returning an
object which is shared between the multiple threads within the servlet (each
invocation of a servlet is likely to be on a different thread). Look at where
the object you are returning is defined. Is it within the service method? If
not then it is most likely shared between threads and must be synchronized.

Unfortunately it's impossible to be more specific without more specific details.

Signature

Nigel Wade, System Administrator, Space Plasma Physics Group,
           University of Leicester, Leicester, LE1 7RH, UK
E-mail :    nmw@ion.le.ac.uk
Phone :     +44 (0)116 2523548, Fax : +44 (0)116 2523555

prabodhachyutha@gmail.com - 10 Jul 2007 10:27 GMT
Thanks for all your support. We solved the problem. Problem is badly
written client side code. For the every request, client is invoking a
thread. In run() method it is loading the DTO(object) to the same
class's field.

public void run() {
                try {
                    dto = getData(obj);
                } catch (Exception e) {}
            }

Here getData() method is processing the server response and returning
it. But two threads are referring same "dto". (Note: dto is not method
local, it is class variable).

We solved this by threads sychornization.

>  prabodhachyu...@gmail.com wrote:
> > All,
[quoted text clipped - 29 lines]
>
> - Show quoted text -
Roedy Green - 04 Jul 2007 03:48 GMT
On Tue, 03 Jul 2007 08:23:02 GMT, Esmond Pitt
<esmond.pitt@nospam.bigpond.com> wrote, quoted or indirectly quoted
someone who said :

>This is not so: see the Serialization Specification, section on Versioning.

In practice it is. Try writing some code. It is not nearly as robust
as you would suspect from the docs.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Esmond Pitt - 04 Jul 2007 05:48 GMT
> In practice it is. Try writing some code. It is not nearly as robust
> as you would suspect from the docs.

I've written lots of serialization code, thanks, and I haven't
encountered any problems whatsoever when sticking to the versioning
constraints specified.

What specific problems have you encountered?
Roedy Green - 09 Jul 2007 21:24 GMT
On Wed, 04 Jul 2007 04:48:58 GMT, Esmond Pitt
<esmond.pitt@nospam.bigpond.com> wrote, quoted or indirectly quoted
someone who said :

>I've written lots of serialization code, thanks, and I haven't
>encountered any problems whatsoever when sticking to the versioning
>constraints specified.

But you are not a novice.  A novice will inevitably trip.  So I
suggest for a novice you ensure all classes and serial IUDs are
identical read and write.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Esmond Pitt - 10 Jul 2007 02:37 GMT
> But you are not a novice.  A novice will inevitably trip.  So I
> suggest for a novice you ensure all classes and serial IUDs are
> identical read and write.

You're misquoting. Clearly I was commenting on your statement that 'all
classes transported must have identical ... non-transient fields' and
your subsequent apparent claim that the Versioning provisions of
Serialization aren't 'nearly as robust as you would suspect from the
docs'. If that's not what you're saying, we agree. If it is what you're
saying, I'd like some chapter and verse as to exactly what doesn't work
and where it is acknowledged in the Bug Parade.
Matt Humphrey - 03 Jul 2007 13:28 GMT
| Hi,
|
[quoted text clipped - 62 lines]
| }
| }

Your writing code looks reasonable, other than the empty exception handler.
Are you sure that every object that is reachable from your
DataTransferObject is also serializable every time you write data?   What
does your reading code look like?  There are ways to miscode reading that
will cause the problem (e.g. expecting the data to arrive in a single
packet.)

Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/
Esmond Pitt - 04 Jul 2007 05:50 GMT
> I got a problem when sending the data from the serverside and getting
> it back in the client side. We are not getting the object(here it is
> DataTransferObject which is Serializable) as null in the client side.

If you are getting a null, *and no exceptions*, at the client, and no
exceptions at the server, it can only mean that the object reference was
null when you serialized it.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.