[jboss-user] [JBoss Remoting] - Re: JBoss Remoting and compression
Doychin Bondzhev [http://community.jboss.org/people/doychin] created the discussion "Re: JBoss Remoting and compression" To view the discussion, visit: http://community.jboss.org/message/560353#560353 -- Looks like compression is not good for RMI especially when you have fast network. Even the smallest call to the server takes to much time to complete. Application looks slow. After removing compression it is now like a rocket ;-) -- Reply to this message by going to Community [http://community.jboss.org/message/560353#560353] Start a new discussion in JBoss Remoting at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2050] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket invocator and long transactions
All these new things in Remoting 3 are great but at least in my case it is all up to the integration code that is provided on top of remoting by Application server client library. I'm not sure how this is going to work with these asynchronous calls. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216430#4216430 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216430 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket invocator and long transactions
Hi Ron, As you know there is timeout parameter which is used to wait on the socket read/write operation. This timeout if is less then the user transaction timeout on the client side and for some reason execution at the server takes more time then this timeout it will crash execution again. Client side will exit read and will try to send same command to the server. It will write some parts of invocation it and will start waiting again for second round on the timeout. This data will stay in the socket and probably will create some problems when the server side tries to read data from socket later. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214754#4214754 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214754 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket invocator and long transactions
Hi Ron, Are there any plans to make change in remoting so that it can talk with transactions code and respect user transaction timeout? What are the possibilities for this? Is this a problem that has to be solved from Application Server developers or it is a problem for Remoting guys? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214473#4214473 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214473 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket invocator and long transactions
Here is what I found until now. I'm using JBoss App Server 4.2.3 GA with it's original version of jboss remoting. One specific change I did to the remoting configuration was to add idleTimeout parameter with value 120 seconds. So from here start my problems. Without this timeout all will be fine. When it is specified the IdleTimer will close sockets for all inactive ServerThread instances including those that current are busy processing some request. (In SocketServerInvoker.java the problem comes from calls like this: svrThread.unblock();) When such socket is closed on the sever the client side sends another instance of the same request(invocation) and as result I get an exception for the second request (Application Error: no concurrent calls on stateful beans). In the initial thread I get exception that Transaction status is ABORTING. All these findings are valid for all versions of JBoss Remoting 2.2.2. For 2.4 I see that all calls to shutdown and unblock method are commented and replaced just with call to shutdown later in the code. Regarding UserTransaction timeouts there is still problem. At least I can't find anything in the code that will respect the value for user transaction timeout. They will work only if their timeout is less then the timeout value specified in jboss-service.xml. Doychin View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211834#4211834 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211834 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Socket invocator and long transactions
Looks like there is some problem with long running transactions when used with socket invocation. I found that no matter what I will specify for transaction time out I get exception from server for trying to call statefull bean second time after 6 minutes. I'm sure there is no second call and that second call comes from the same thread that created the first call so it is not in my code but instead something internally in client side remoting code. >From what I see it looks like jboss remoting client code does not respect the >availability of UserTransaction and it's timeout. Is there a solution for this problem or and updated version of remoting that supports user transactions? Is the only solution is now to increase the timeout for invocation? If I increase it to much isn't that a source for more problems later? Doychin View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211696#4211696 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211696 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - How to put EJB 2.1 Entity + EJB 3 session in signle JAR
I have one large project that consists of few EJB 2.x modules each of them containing some Session and Entity beans. What I want to do is to migrate all Session beans to use EJB 3 annotations but still use the EJB2.x entity beans and moving them slowly to JPA. Is this possible with JBoss and if it is how I have to package these? If you can provide some tips or examples it will be great. Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205334#4205334 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205334 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB/JBoss] - Re: Transaction timeout
In such cases I usually prefer to use User transaction. This way you can control transaction timeout from within your code. Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205044#4205044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205044 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB/JBoss] - Can I mix EJB2.1 Entity beans with EJB 3 Session/Message bea
I tried this before with JBoss 4.2.3 but looks like EJB 3 deployer does not process the deployment descriptors for EJB 2.x entity beans. So can I do this with JBoss 5? Is this going to be supported by JBoss AS? I found JIRA reports about this but there was only mention that this might happen some time in the future. Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205041#4205041 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205041 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Using remoting for RMI for EJB 2 with scoket connector a
I think my problem is releated to this JIRA https://jira.jboss.org/jira/browse/JBAS-4586 Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202075#4202075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202075 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: JBoss Remoting and compression
You can find the source code of compression invoker marshaller/unmarshaller as attachments in the JIRA report. Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199384#4199384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199384 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Using remoting for RMI for EJB 2 with scoket connector a
Thanks for the tip. It did the trick. Now I reverted to original option values and added that extra option. Doychin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199343#4199343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199343 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: JBoss Remoting and compression
In order to allow compression to work with EJB 2.x invocations I created my own
Compression marshaller and unmarshaller which descend from original classes.
The default constructor for both classes now call the constructor that takes
one parameter of type Marshaller/UnMarshaller with new
InvocationMarshaller()/InvocationUnMarshaller().
I also did new versions of read/write methods which I use to test different
variants for calling GZip streams.
>From my experiments I can tell that switching
oos.flush(); and gzos.finish();
does not help.
I'm still getting exceptions for incorrect version in the stream. But I also
found a solution which is in the code below.
In order to workaround the other problem with OutOfMemory exception I created
new GZip input/output stream classes that descend from the original Java
classes.
in my Output stream I added new finish method
public void finish() throws IOException
| {
| super.finish();
| def.end(); // This will release all resources used by zlib
| }
| }
in the input stream I added new method
public void end() throws IOException
| {
| while (available() > 0) { // This tell the gzip input stream to
read the extra trailer put by finish method in output stream. This all removes
the need to use buffered stream like in 2.x branch
| read();
| }
| inf.end();
| }
|
and I call this new method at the end of read method.
this way I can use original java GZip classes without having to relay on
external libraries.
- inf and def are protected fields in Java 1.5 and 1.6
If you want I can provide you with full source code so you can use it to create
the necessary updates in 2.x and 2.2 branches.
Doychin
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199342#4199342
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4199342
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Using remoting for RMI for EJB 2 with scoket connector and c
Here is the configuration of my application which I'll use to describe my problems, findings and solutions - JBoss App server 4.2.3 with EJB 2.x application - JBoss remoting 2.2.2. SP8 - Swing client application that uses JBoss remoting to talk to the app server - Using jboss serialization over the wire. My problem lies in the way my client application works with application server. I'm using in some cases multiple threads to load different kinds of data from application server. In that case I end up with many socket connections open from one client to the server. These connections remain open while that client is still active no matter are they used or not. In my case usually these are around 30. In case there are many active clients at the same time this creates big problem. The system works OK up to the point where maxPoolSize number of server threads is reached and from there starts the problem. Because that limit is reached server now tries to free some ServerThread instance but it can't until it's timeout is reached. This leads to a situation where client application freezes for some time and this could be very long time. This of course leaves the end user with feeling that the application freezes and the usually restart the client after few minutes of waiting. In order to fix this problem I had to make changes to some of the settings for socket connection in jboss-service.xml What I changed was to set clientMaxPoolSize to 5 (it was 50 by default). This will allow up to 5 simulations connection open to the server from a single client application. Another change I did was to add continueAfterTimeout parameter and to set it to false. It's default value of true prevents the server from closing unused connections after the timeout has expired. Now with these settings my app server can handle up to 60 active clients and even more if the maximum amount of allowed client connections is not used by all of them. Doychin Bondzhev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198691#4198691 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198691 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - JBoss Remoting and compression
I've spent some time digging into compression and I managed to make it work with JBoss 4.2.3 and Remoting 2.2.2SP8. The problem I found was with an error previously described in another post. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134557 The problem comes from some extra bytes put in the output stream from compression and not read from decompression. These extra bytes still there after unmarshalling is completed. Next time when unmarshaller reads version from the input stream it reads these extra bytes and generates the error for incorrect version. In most recent versions I see that BufferedInputStream is used to workaround this problem but I'm not sure this will work always. There is always a small chance that the serialized compressed data that contains these extra bytes is just a few bytes longer then the size of the buffer in the buffered input stream. So after unmarshalling is complete they will still in the socket input stream and lead again to same version error. Of course the use of BufferedInputStream reduces the chance for this error but it is still exists. What I did to make sure it will never happen was to put the size of of the compressed data before it in the output stream and during the unmarshaling to read that size and then read the specified amount of bytes from the input stream. Also another problem I found with current solution is that it leaks lots of memory when it is used to transfer big amounts of data for short period of time. The reason is that GZip streams depend on some native code routines in JVM and to release the resources used by these routines streams depend on the garbage collector to call their finalize methods. Another way to release that method is to call close method on the GZip output stream but this will also close the underlying stream(in this case it is the buffered stream which will close the socket output stream). In order to avoid that I used instead ByteArrayOutputStream on the marshaling side and ByteArrayInputStream on the unmarshaling side to store the compressed data to byte array and then to write that byte array to the socket output stream/read from input stream to byte array and then pass that byte array to GZip input stream. Now when I have separated the socket streams from GZip streams I can call close on these in order to release the memory used during the compress/decompress process. I hope these comments will help other people to avoid the same problems I faced already. Doychin Bondzhev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198688#4198688 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198688 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
