[javaflow] debug code

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[javaflow] debug code

Kohsuke Kawaguchi

Torsten,

I made a few changes so that debug code doesn't run by default (I don't
think applications want to see the class file dumps in the current
directory!) I hope this change is OK with you.

I have a few other debug code related issues.

The first one is easy one. I saw that javaflow.jar ships with
simplelog.properties, which configures the logger to print the debug
messages. Shouldn't this file be moved to the src/test?

Second, because of the way javaflow instruments 'new' instruction, every
constructor argument goes through a Stack object.

So when the code is like:

void foo() {
   InputStream is = new BufferedInputStream(new FileInputStream(...));
   ...
   is.close();
   is = null;

   Continuation.suspend();
}

I still get a warning saying "FileInputStream is not serializable" when
the first line is executed (not when the execution suspends.) When we
are capturing the stack, this warning message could be useful
(especially because it can point to a specific stack frame), but this
false positive isn't desirable. Also, there are perfectly good use cases
  of javaflow that doesn't involve in serialization.

So I'm wondering what to do with this.

One idea that occurred to me is that when we see a non-serializable
object pushed into a stack, we just create an exception without throwing it.

Later in the writeObject method, if a non-serializable object is going
to be serialized, we can use this exception to tell users where this
object was captured.

Or you might think it's a non-issue (in the sense that users can just
turn off the logging to get rid of the warnings.)


The trouble I have in the workflow engine is that I want to ship it with
logging turned off by default (because of those false-positives), but
when there's actually a problem, I want to provide a meaningful errors
right away. Telling them to manually turn on the logging won't be a very
good user experience.

--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [javaflow] debug code

Torsten Curdt
> I made a few changes so that debug code doesn't run by default (I  
> don't think applications want to see the class file dumps in the  
> current directory!) I hope this change is OK with you.

Hehe :) Sure

> I have a few other debug code related issues.
>
> The first one is easy one. I saw that javaflow.jar ships with  
> simplelog.properties, which configures the logger to print the  
> debug messages. Shouldn't this file be moved to the src/test?

Well, would probably be good enough.

> Second, because of the way javaflow instruments 'new' instruction,  
> every constructor argument goes through a Stack object.

<snip/>

> I still get a warning saying "FileInputStream is not serializable"  
> when the first line is executed (not when the execution suspends.)

<snip/>

> So I'm wondering what to do with this.
>
> One idea that occurred to me is that when we see a non-serializable  
> object pushed into a stack, we just create an exception without  
> throwing it.

TBH ...that's one of the things were
I wasn't sure either. Actually what
I was thinking is that it would be
much better to provide an API where
you can register a listener so you
get notified about the non-serializable
objects.

WDYT?

> The trouble I have in the workflow engine is that I want to ship it  
> with logging turned off by default (because of those false-
> positives), but when there's actually a problem, I want to provide  
> a meaningful errors right away. Telling them to manually turn on  
> the logging won't be a very good user experience.

Sure

cheers
--
Torsten (who is still working through a 3 weeks backlog of emails)


PGP.sig (193 bytes) Download Attachment