Hi. Open Scanner for .META is working well in the transnational table (I put break points in deferent levels , including region server and ScannerCallable), I don't know if this is indication for something. Tomorrow I'll try to use regular HTable (requires some work in our infrastructure). Any way, the exception that is thrown from the ScannerCallable in the case of no connection to the server after 10 retires should be more informative and probably the flow of ScannerCallable shouldn't continue to call method next() in the region server with default value for scanner ID =-1.
I'll let you know tomorrow about my ties using regular HTable. Thank You and Best Regards. On Wed, Apr 28, 2010 at 7:45 PM, Stack <st...@duboce.net> wrote: > Does it work if not transactional in the mix? That might help narrow > down what is going on here? > St.Ack > > On Tue, Apr 27, 2010 at 6:51 AM, Slava Gorelik <slava.gore...@gmail.com> > wrote: > > Hi to All. > > Tried to investigate a bit this problem in the debugger. > > It looks like the failure is in connecting region server to open scanner. > > And it seems that there problem to connect region server to open scanner > (in > > any other cases region server is available > > for example for put/get operations) , after 10 tries the scanner ID is > still > > -1 and it passed to the region server (somehow > > in this case connection with region server is succeeded) and server throw > an > > exception about wrong scanner name. > > > > I have only one region server that is on the same machine where master is > > located (single node installation - not a pseudo, > > including zookeeper) and also I'm using transactional table (from > contrib). > > > > Any idea what could be a problem ? > > > > Best Regards. > > > > > > > > On Thu, Mar 18, 2010 at 5:54 PM, Slava Gorelik <slava.gore...@gmail.com > >wrote: > > > >> Hi. > >> I also don't have any solution yet. > >> > >> Best Regards. > >> > >> > >> > >> On Thu, Mar 18, 2010 at 8:29 AM, Alex Baranov <alex.barano...@gmail.com > >wrote: > >> > >>> I have a similar problem, but even with standard filter, when I use it > on > >>> the remote client ( > >>> > >>> > http://old.nabble.com/Adding-filter-to-scan-at-remote-client-causes-UnknownScannerException-td27934345.html > >>> ). > >>> > >>> Haven't solved yet. > >>> > >>> Alex Baranau > >>> > >>> On Tue, Mar 16, 2010 at 8:12 PM, Slava Gorelik < > slava.gore...@gmail.com > >>> >wrote: > >>> > >>> > Hi Dave. > >>> > Thank You for your reply, but all .out files (master and region > server) > >>> are > >>> > empty from any exception. > >>> > > >>> > Best Regards. > >>> > > >>> > On Tue, Mar 16, 2010 at 7:45 PM, Dave Latham <lat...@davelink.net> > >>> wrote: > >>> > > >>> > > Is there anything informative in the .out file? I remember one > time I > >>> > had > >>> > > an error in a filter's static initializer that caused the class to > >>> fail > >>> > to > >>> > > load, and it manifested as an uncaught NoClassDefFoundError ( > >>> > > https://issues.apache.org/jira/browse/HBASE-1913 ) showing up > there > >>> > > instead > >>> > > of the .log file. > >>> > > > >>> > > Dave > >>> > > > >>> > > On Tue, Mar 16, 2010 at 9:52 AM, Slava Gorelik < > >>> slava.gore...@gmail.com > >>> > > >wrote: > >>> > > > >>> > > > Hi. > >>> > > > Sure i restarted both sides. > >>> > > > The log has ony one exception that I specified - Name: -1. > >>> > > > Scanner on .META and .ROOT are works fine (I put break points on > >>> call() > >>> > > > method that > >>> > > > actually calls openScanner() and till my scanner it works fine). > >>> > > > > >>> > > > Best Regards. > >>> > > > > >>> > > > On Tue, Mar 16, 2010 at 5:39 PM, Stack <st...@duboce.net> wrote: > >>> > > > > >>> > > > > On Tue, Mar 16, 2010 at 1:42 AM, Slava Gorelik < > >>> > > slava.gore...@gmail.com> > >>> > > > > wrote: > >>> > > > > > Hi. > >>> > > > > > I added my filters to the HbaseObjectWritable but the problem > is > >>> > not > >>> > > > > solved. > >>> > > > > > > >>> > > > > > >>> > > > > And for sure you restarted both sides of the connection and > both > >>> > sides > >>> > > > > are same compiled code? > >>> > > > > > >>> > > > > If so, next up will be seeing whats in the log over on the > server. > >>> > > > > Mismatched interfaces are ugly to debug. The messages that > come > >>> out > >>> > > > > don't tell much about whats actually wrong. If you remove your > >>> code, > >>> > > > > all works fine? So its just the addition of your filters that > is > >>> the > >>> > > > > prob? > >>> > > > > > >>> > > > > St.Ack > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >> > >> > > >
