Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[Java] WriteObject & ReadObject probleem

Pagina: 1
Acties:

  • mousekraker
  • Registratie: Maart 2013
  • Laatst online: 18:46
Ik hoop dat iemand mij kan helpen met het volgende probleem:

Ik heb een client en een server waartussen ik een aantal objecten heen en weer wil sturen.

Client:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
private ObjectOutputStream out;

private void connect()
{
    this.out = new ObjectOutputStream(this.Socket.getOutputStream());
}

public void send(Response response)
{
   try 
   {
            this.out.writeObject(response);
            this.out.flush();            
   } 
   catch (IOException ex) 
   {
            Logger.getLogger(Connection.class.getName()).log(Level.SEVERE, null, ex);
   }
}


Server
Java:
1
2
3
4
5
6
7
8
ergens gedefineerd:
this.ObjIn = new ObjectInputStream(this.socket.getInputStream());

in een thread
try 
{
    Response response = (Response)this.ObjIn.readObject();                                            
}


Ik ben nu bezig met het versturen van een gebruikersnaam en wachtwoord naar de server. Dit doe ik via 1 object: response. De eerste keer dat ik deze informatie stuur komt alles netjes binnen (object is hetzelfde bij de client en server). Als ik een tweede keer een andere gebruikersnaam en wachtwoord verstuur gebeurd er in mijn ogen iets vreemds. De variabel response aan de server kant is dan gelijk aan het eerder ontvangen object, terwijl een ander object verstuurd is.

Via google word ik niet veel wijzer. Ik weet niet echt op welke zoektermen ik hiervoor moet zoeken. Aan de server zijde heb ik ook BufferedInputStream gebruikt, maar dat lost het probleem niet op.

Is er iemand zo vriendelijk die mij in de juiste richting kan sturen? Ik ben erg benieuwd naar waarom dit gebeurd en wat de oplossing hiervoor is.

  • Infinitive
  • Registratie: Maart 2001
  • Laatst online: 25-09-2023
Weet je zeker dat je de stream van het juiste socket-object leest, en dat je het object van het juiste streamobject leest?

Daarnaast gaat bij mij bij het woordje "thread" and "iets vreemds" een alarmbelletje rinkelen...

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]


  • mousekraker
  • Registratie: Maart 2013
  • Laatst online: 18:46
Infinitive schreef op vrijdag 19 juli 2013 @ 17:03:
Weet je zeker dat je de stream van het juiste socket-object leest, en dat je het object van het juiste streamobject leest?

Daarnaast gaat bij mij bij het woordje "thread" and "iets vreemds" een alarmbelletje rinkelen...
Bedankt voor het meedenken :) . Van al het bovenstaande weet ik zeker dat het werkt. De thread is niet zoveel speciaals nog, 1 per client. Ik ben nog maar met 1 client aan het testen, dus dat is nog geen probleem.

Blijkbaar ligt het aan het object dat ik over en weer stuur. Deze is Serializable en veroorzaakt dit probleem blijkbaar. Door this.out.reset(); uit te voeren voordat er gegevens verstuurd worden, krijg ik nu wel de juiste data binnen bij de server. Nu alleen nog uitzoeken waarom dit zo is.

  • Merethil
  • Registratie: December 2008
  • Laatst online: 22:17
mousekraker schreef op vrijdag 19 juli 2013 @ 17:13:
[...]


Bedankt voor het meedenken :) . Van al het bovenstaande weet ik zeker dat het werkt. De thread is niet zoveel speciaals nog, 1 per client. Ik ben nog maar met 1 client aan het testen, dus dat is nog geen probleem.

Blijkbaar ligt het aan het object dat ik over en weer stuur. Deze is Serializable en veroorzaakt dit probleem blijkbaar. Door this.out.reset(); uit te voeren voordat er gegevens verstuurd worden, krijg ik nu wel de juiste data binnen bij de server. Nu alleen nog uitzoeken waarom dit zo is.
Is het niet een kwestie van:

Java:
1
2
3
4
5
6
 try  
   { 
            this.out.writeObject(response); 
            this.out.flush();
            this.out.close();             
   }  


De close toevoegen?
Je gebruikt een output object, volgens mij moet die eerst gesloten worden voor je weer een nieuw object aanmaakt en vult, anders blijft hij het oude object gebruiken.
Flush is vziw niets meer dan ervoor zorgen dat alle informatie inderdaad verwerkt is, waarna je het object nog moet sluiten om opnieuw te initialiseren de volgende keer.

Edit: Als je dit doet zal je ook de connect opnieuw moeten aanroepen, anders heb je volgens mij een nullpointerexception de volgende keer, aangezien je connectie niet meer openstaat.
Probleem zonder de close is dat je object niet geleegd wordt.

[ Voor 9% gewijzigd door Merethil op 19-07-2013 20:34 ]


  • mousekraker
  • Registratie: Maart 2013
  • Laatst online: 18:46
Close zal vast en zeker het probleem oplossen, maar dat is natuurlijk niet handig. Zoals ik al zei lost het resetten van de stream het probleem op. Bij het versturen van een Serializable object onthoudt de stream het object. Bij het opnieuw versturen van dit object, wordt niet het object zelf verstuurd maar een soort referentie. Zelfs wanneer het object is aangepast wordt enkel de referentie verstuurd. Bij de server is dus niet bekend dat het object is aangepast. Door de stream te resetten wordt afgedwongen om het object te versturen ipv de referentie.